LECTURE NOTES

Pattern Software Design

Minggu 6
Sesi 11

Domain Services and Events

COMP6299 - Pattern Software Design

 LEARNING OUTCOMES

LO 1: Menjelaskan dan mengidentifikasi konsep pola Desain

LO 2: Menjelaskan permasalahan yang harus dipecahkan.
LO 3: Menjelaskan permasalahan bisnis dalam domain
LO 4: Merancang solusi untuk domain permasalahan bisnis.

OUTLINE MATERI (Sub-Topic):

• Memahami Layanan Domain

• Memanfaatkan Layanan Domain
• Esensi dari Pola Domain event
• Tindakan Penanganan event
• Pola Implementasi Domain event
• Menguji Domain event

COMP6299 - Pattern Software Design

 ISI MATERI

1. Memahami Layanan Domain

Layanan domain mewakili konsep domain; mereka adalah perilaku yang ada di
masalah domain, mereka terjadi dalam percakapan dengan pakar domain, dan
mereka tentu saja merupakan bagian dari ubiquitous language (UL). Beberapa
karakteristik teknis dari layanan domain penting untuk diperhatikan sehingga Anda
dapat memodelkannya dalam kode Anda secara efektif.
A. Kapan Menggunakan Layanan Domain
Anda telah berbicara dengan pakar domain tentang konsep domain yang
melibatkan banyak entitas, tetapi Anda tidak yakin tentang entitas mana
yang “memiliki” perilaku tersebut. Tampaknya bukan milik salah satu dari
mereka, dan rasanya canggung ketika Anda mencoba memaksakannya ke
salah satu dari mereka. Pola berpikir ini merupakan indikator kuat akan
perlunya layanan domain.
1) Mengenkapsulasi Kebijakan dan Proses Bisnis
Perhatian utama untuk layanan domain adalah melakukan beberapa
perilaku yang melibatkan entitas atau objek nilai.
2) Mewakili Kontrak
Kasus penggunaan luas lainnya untuk layanan domain adalah sebagai
kontrak — di mana konsep itu sendiri penting bagi domain, tetapi
implementasinya bergantung pada infrastruktur yang tidak dapat
digunakan dalam model domain.
Anda dapat menggunakan layanan domain sebagai kontrak untuk
berbagai skenario, termasuk:
• Identifikasi entitas
• Pencarian nilai tukar
• Pencarian pajak
• Pemberitahuan waktu nyata
B. Anatomi Layanan Domain
Layanan domain memiliki tiga karakteristik teknis mendasar: mereka
mewakili perilaku, dan dengan demikian tidak memiliki identitas; mereka tak
bernegara; dan mereka sering mengatur banyak entitas atau objek domain.
C. Menghindari Model Domain Anemik
tidak semua logika domain perlu hidup pada entitas secara langsung dan
bahwa layanan domain adalah konsep yang berguna, Anda harus berhati-
hati untuk tidak mendorong terlalu banyak logika ke dalam layanan domain,
yang dapat menyebabkan model domain yang tidak akurat,
membingungkan, dan anemia dengan kohesi konseptual yang rendah .
Menemukan keseimbangan yang tepat antara terlalu sedikit dan terlalu
banyak layanan domain lebih mudah dengan pengalaman.

D. Membandingkan dengan Layanan Aplikasi

COMP6299 - Pattern Software Design

 Layanan Domain Layanan aplikasi

Mewakili konsep yang ada dalam
domain masalah, dan setidaknya,
antarmuka mereka hidup dalam
model domain.
tidak mewakili konsep domain, dan
mereka tidak mengandung aturan
bisnis dan layanan aplikasi yang
hidup di lapisan layanan dan
kesepakatan akan menyatukan
masalah infrastruktur, seperti
transaksi, untuk melaksanakan
kasus penggunaan penuh bisnis.

Tidak tinggal di lapisan layanan hidup di lapisan layanan dan

dan tetapi kesepakatan akan kesepakatan akan menyatukan
menyatukan masalah masalah infrastruktur, seperti
infrastruktur, seperti transaksi, transaksi, untuk melaksanakan
untuk melaksanakan kasus kasus penggunaan bisnis penuh
penggunaan bisnis penuh
mengandalkan infrastruktur yang perhatian infrastruktur dalam
digunakan untuk layanan aplikasi ada untuk
menginformasikan logika domain. memungkinkan model domain
keprihatinan infrastruktur dalam untuk mengeksekusi dengan benar
layanan aplikasi ada untuk
memungkinkan model domain
untuk mengeksekusi dengan
benar
membuat panggilan HTTP ke membungkus model domain dalam
layanan web atau menulis sesuatu transaksi atau membuat koneksi
ke disk sebagai bagian dari logika basis data sehingga kode dapat
domain berjalan sebagai satu kasus
penggunaan

2. Memanfaatkan Layanan Domain

Detail yang tersisa adalah memahami bagaimana menggunakannya. Beberapa opsi
memerlukan sedikit penjelasan, seperti halnya menggunakan layanan domain di
dalam layanan aplikasi. Namun, yang kontroversial, layanan domain sering perlu
digunakan sebagai langkah dalam proses domain yang sepenuhnya berada dalam
model domain. Ini mengarah pada perdebatan bagaimana layanan domain ke
entitas.

A. Dalam Lapisan Layanan

Layanan domain dapat digunakan dalam layanan aplikasi. Sebagai bagian dari
perannya dalam memenuhi kasus penggunaan bisnis penuh, layanan aplikasi
dapat menarik entitas yang relevan dari repositori dan meneruskannya ke
layanan domain

COMP6299 - Pattern Software Design

B. Dalam Domain
Terkadang entitas membutuhkan layanan domain untuk melakukan perilakunya
dengan cara yang menghalangi menyatukan mereka dalam layanan aplikasi.
Contoh khas adalah ketika pemberitahuan harus terjadi setelah entitas
menjalankan beberapa tugas.
seringkali object relational mappers (ORM) digunakan untuk mengelola siklus
hidup entitas, menghilangkan kemampuan pengembang untuk meneruskan
dependensi pada konstruksi objek. Masing-masing teknik berikut bertujuan
untuk meringankan masalah ini.
1) Wiring Secara Manual
Jika suatu entitas atau objek domain lain bergantung pada layanan
domain, Anda bisa meneruskan layanan yang relevan ke konstruktor jika
Anda mengelola sendiri konstruksi objek.
2) Menggunakan Injeksi Ketergantungan
Menggunakan injeksi dependensi menghemat kerumitan membuat objek
secara manual. Ini terutama masalah gaya apakah Anda memilih ini atau
secara manual memasang dependensi Anda, karena masalah berurusan
dengan ORM mungkin masih ada.
3) Menggunakan Pencari Layanan
Masalah sebenarnya dengan menggunakan pelacak layanan muncul dari
berpasangan yang ketat; Anda harus memisahkan dalam tes Anda,
misalnya. Masalah lain adalah mengaburkan ketergantungan suatu objek,
karena mereka tidak lagi diteruskan ke konstruktor.
4) Menerapkan Pengiriman Ganda
Jika Anda senang melepaskan layanan domain ke entitas pada waktu
konstruksi, Anda memiliki opsi untuk meneruskannya sebagai argumen
metode menggunakan pola pengiriman ganda. Dengan pengiriman ganda,
layanan domain dilewatkan ke dalam metode pada entitas, dan entitas
kemudian beralih ke metode pada layanan domain.
Pengiriman ganda tidak sesuai dengan keinginan semua orang, tetapi juga
tidak ada opsi lain yang disajikan sejauh ini. Pasti paling baik untuk
mengeksplorasi ide itu sendiri dan menilai bagaimana itu bekerja pada
proyek Anda. Salah satu pendekatan yang telah menjadi populer, adalah
menggunakan pola domain event, dengan janji entitas yang benar-benar
memisahkan dari layanan domain.
5) Decoupling dengan Domain event
Pola menarik yang sepenuhnya menghindari kebutuhan untuk
menyuntikkan layanan domain ke entitas adalah domain event. Ketika
tindakan penting terjadi, suatu entitas dapat meningkatkan a domain event
yang ditangani oleh pelanggan yang terdaftar untuk event itu. Seperti yang
mungkin sudah Anda duga, layanan domain dapat berada dalam
pelanggan, dan karena itu, bukan entitas.
6) Haruskah Entitas Tahu Tentang Layanan Domain?
Dalam contoh sebelumnya, Anda melihat bagaimana domain event
mencegah menyuntikkan layanan domain ke entitas, sedangkan masing-
masing pola lainnya berjalan di arah yang berlawanan dan mencoba

COMP6299 - Pattern Software Design

 menemukan cara untuk membuat ketergantungan layak. Yang terakhir
adalah pendekatan yang cukup kontroversial dalam komunitas DDD;
banyak praktisi berpendapat bahwa itu hanya ide yang buruk. Pada
akhirnya, Anda perlu menggunakan konteks, preferensi pribadi, dan
pengalaman Anda untuk memutuskan opsi mana yang paling Anda sukai.

3. Esensi dari Pola Domain Event

Pada dasarnya, Anda menggunakan komponen infrastruktur, kadang-kadang dari
dalam model domain Anda, untuk mempublikasikan event. Secara default, event
kemudian diproses serentak dalam thread yang sama oleh masing-masing event
handler yang telah terdaftar untuk jenis event. Penanganan event yang tidak sinkron
juga dimungkinkan dengan pola ini.
A. Opsional Asinkron
Menggunakan pola domain event dapat sinergis dengan alur kerja asinkron,
termasuk komunikasi antara konteks yang dibatasi. Pesan asinkron antara
konteks terbatas adalah solusi modern yang membantu dengan keandalan dan
skalabilitas. Anda dapat memicu proses ini dari dalam domain event event
handler Anda. Kadang-kadang Anda bahkan ingin komunikasi asinkron dan
andal dalam konteks terbatas, untuk skenario seperti menerapkan agregat yang
akhirnya konsisten. Menggunakan sifat domain event yang dipisahkan dapat
membantu Anda dalam kedua skenario.
Yang penting, saat membuat event handler yang memicu alur kerja tidak
sinkron, Anda harus jelas tentang batasan transaksional. Misalnya, jika satu
penangan event memperbarui basis data, dan yang lainnya menerbitkan pesan,
Anda ingin kedua operasi untuk memutar kembali jika salah satu dari mereka
gagal

Memastikan perilaku transaksional yang benar Scott Millett. (2015).

COMP6299 - Pattern Software Design

 B. Event Internal vs Eksternal
Internal Eksternal

Event terbatas dalam ruang lingkup Event cenderung datar dalam

untuk konteks terbatas tunggal, struktur, memperlihatkan hanya
tidak apa-apa untuk menempatkan beberapa properti — sebagian besar
objek domain pada mereka. waktu hanya ID korelasional

Jika Anda membuat perubahan pada Event perlu diversi untuk

Event internal, kode Anda tidak akan menghindari kerusakan
dikompilasi (jika menggunakan
bahasa pemrograman yang
dikompilasi)
Kasus penggunaan bisnis yang khas Hanya satu atau dua Event eksternal
mungkin ada sejumlah Event internal yang dimunculkan oleh lapisan
yang diangkat layanan

Alur event internal dan eksternal dalam kasus penggunaan bisnis (Scott
Millett. (2015)).

4. Tindakan Penanganan Event

Memahami perbedaan antara penangan di domain dan penangan di lapisan layanan
aplikasi. Meskipun mereka terlihat sama, tanggung jawab mereka sangat berbeda.
Penangan domain event menggunakan logika domain, seperti memohon layanan
domain, sedangkan penangan event layanan lapisan aplikasi lebih bersifat
infrastruktur, melaksanakan tugas-tugas seperti mengirim email dan menerbitkan
event ke konteks terbatas lainnya.
A. Menyerukan Logika Domain
event handler yang ada dalam model domain dapat menangani event yang
terjadi di sana. Skenario ini adalah pemodelan urutan interaksi yang terjadi di
domain masalah. Misalnya, di toko takeaway online, validator pesanan
memvalidasi pesanan, memverifikasi bahwa pelanggan tidak masuk daftar
hitam setelah gagal membayar pesanan sebelumnya.

COMP6299 - Pattern Software Design

 B. menyerukan Logika Aplikasi
Ada manfaat untuk memiliki event handler yang hidup di lapisan layanan
aplikasi selain orang-orang yang hidup di domain. Event Handler ini cenderung
melakukan tugas-tugas infrastruktur seperti mengirim e-mail. Perhatikan bahwa
penangan ini bukan bagian dari UL atau domain.
Salah satu tanggung jawab penting dari handler lapisan layanan aplikasi adalah
mereka memicu komunikasi dengan konteks terikat eksternal. Mereka juga
mengelola komunikasi dengan layanan eksternal, seperti gateway pembayaran.

5. Pola Implementasi Domain Event

domain event adalah pola umum yang pada dasarnya menambahkan semantik
domain ke pola publikasi-berlangganan. Ini memberi Anda banyak kebebasan untuk
mengimplementasikan solusi. Anda akan melihat berbagai opsi dalam contoh berikut
yang berkisar dari penggunaan konstruksi bahasa asli yang sinkron, hingga alternatif
berbasis pesan bus.

A. Mengembalikan Domain event

Cara lain dalam pola event domain adalah memisahkan publikasi dan
penanganan event, sehingga efek sampingnya terisolasi. Pendekatan ini
diimplementasikan dengan menyimpan kumpulan event pada root agregat dan
mempublikasikannya setelah root agregat menyelesaikan tugasnya. Secara
signifikan, operator dipanggil dari lapisan layanan untuk menerbitkan event,
menjaga masalah teknis dari model domain.

6. Menguji Domain Event

Menguji kode yang menggunakan pola domain event tidak lebih rumit daripada kode
berorientasi objek tradisional. Di beberapa tempat, itu bahkan dapat disederhanakan
karena kolaborator tidak perlu dipermainkan. Pola pengujian agak berbeda, jadi
bagian ini memberikan panduan singkat dengan contoh.
A. Pengujian Unit
Banyak dari tes unit Anda ingin memverifikasi bahwa entitas atau layanan
domain mengangkat suatu event untuk menandakan perubahan yang terjadi.
dalam pengujian unit, Anda dapat memverifikasi event yang sesuai
dimunculkan dengan mendaftarkan panggilan balik untuknya yang menetapkan
flag.
B. Pengujian Lapisan Layanan Aplikasi
Pengujian integrasi di tingkat layanan-lapisan aplikasi juga dimungkinkan saat
menggunakan domain event Faktanya, testing Anda mungkin terlihat sangat
mirip dengan saat Anda tidak menggunakan event domain. Hal ini karena event
dan event handler hanya rincian pelaksanaan.
Tes ini akan sama apakah pola domain event digunakan atau tidak sebagai
implementasi untuk model domain. Ini menunjukkan bahwa pengujian pada
lapisan layanan aplikasi tidak menambah kompleksitas saat menggunakan
domain event.

COMP6299 - Pattern Software Design

 SIMPULAN
• Kadang-kadang perilaku bukan milik entitas atau objek nilai namun masih
merupakan konsep domain yang penting; ini mengisyaratkan perlunya layanan
domain.
• Ketika suatu entitas bergantung pada layanan domain, berbagai opsi dapat
digunakan, termasuk injeksi ketergantungan, pengiriman ganda, dan domain
event.
• Domain event adalah kejadian signifikan dalam domain masalah dunia nyata;
mereka adalah bagian dari ubiquitous language (UL).
• Domain event juga merupakan pola desain yang membuat domain event lebih
eksplisit dalam kode.
• Penangan event dapat berupa kelas atau panggilan balik anonim / lambdas.
• Beberapa penangan tinggal di domain, dan beberapa tinggal di lapisan layanan.
• Penangan di lapisan layanan biasanya mengambil beberapa tanggung jawab
yang ditangani oleh layanan aplikasi.

COMP6299 - Pattern Software Design

 DAFTAR PUSTAKA
Scott Millett. (2015). Patterns, Principles, and Practices of Domain-Driven Design. 00.
John Wiley & Sons, Inc. Indianapolis.
https://www.thenativeweb.io/blog/2017-11-27-15-17-ddd-and-co-part-5-event-
sourcing/
http://www.carfield.com.hk/document/software+design/dddquickly.pdf
https://jug-saxony-day.org/wp-content/uploads/JSD2018-Ploed-Microservices-Love-
DDD-Version-2018.pdf
https://openpracticelibrary.com/practice/event-storming/
http://www.nada.kth.se/~ann/exjobb/brian_ye.pdf

COMP6299 - Pattern Software Design