Cara memilih antara menggunakan Acara Domain, atau membiarkan lapisan aplikasi mengatur semuanya

Saya sedang mengatur langkah pertama saya ke dalam desain berbasis domain, membeli buku biru dan semuanya, dan saya menemukan diri saya melihat tiga cara untuk mengimplementasikan solusi tertentu. Sebagai catatan: Saya tidak menggunakan CQRS atau Event Sourcing.

Katakanlah permintaan pengguna masuk ke lapisan layanan aplikasi. Logika bisnis untuk permintaan itu (untuk alasan apa pun) dipisahkan menjadi metode pada entitas, dan metode pada layanan domain. Bagaimana saya harus memanggil metode-metode itu?

Opsi yang saya kumpulkan sejauh ini adalah:

• Biarkan layanan aplikasi memanggil kedua metode
• Gunakan metode injeksi / pengiriman ganda untuk menyuntikkan layanan domain ke entitas, membiarkan entitas melakukan hal itu dan kemudian membiarkannya memanggil metode layanan domain (atau sebaliknya, membiarkan layanan domain memanggil metode pada entitas)
• Naikkan acara domain dalam metode entitas, pawang yang memanggil layanan domain. (Jenis acara domain yang saya bicarakan adalah: http://www.udidahan.com/2009/06/14/domain-events-salvation/ )

Saya pikir ini semua layak, tetapi saya tidak dapat memilih di antara mereka. Saya sudah memikirkan hal ini sejak lama dan saya sampai pada titik di mana saya tidak lagi melihat perbedaan semantik di antara ketiganya. Apakah Anda tahu beberapa pedoman kapan harus menggunakan apa?

Biarkan layanan aplikasi memanggil kedua metode

Layanan aplikasi biasanya merupakan tempat awal yang bagus untuk ini, namun Anda harus selalu berusaha mengubah perilaku sedekat mungkin dengan entitas. Layanan aplikasi memainkan peran mengatur dan mengatur panggung untuk mengeksekusi perilaku domain dan dengan demikian menyediakan semua dependensi yang diperlukan. Namun, bila memungkinkan, harus mendelegasikan perilaku ke model domain.

Gunakan metode injeksi / pengiriman ganda untuk menyuntikkan layanan domain ke entitas, membiarkan entitas melakukan hal itu dan kemudian membiarkannya memanggil metode layanan domain (atau sebaliknya, membiarkan layanan domain memanggil metode pada entitas)

Ini adalah pendekatan yang lebih baik karena lebih banyak perilaku didelegasikan ke entitas atau layanan domain. Cara yang paling terpisah untuk mengimplementasikan ini adalah memiliki entitas yang menyatakan ketergantungan pada layanan adalah sebagai parameter dari metode yang menyediakan perilaku yang ada.

Naikkan acara domain dalam metode entitas, pawang yang memanggil layanan domain.

Pola peristiwa domain, seperti dijelaskan oleh Udi dan juga Evans sendiri, cukup fleksibel dan dapat diterapkan dalam berbagai skenario. Ada beberapa komplikasi yang menyertainya. Pertama, Anda harus memastikan bahwa Anda memiliki ruang lingkup yang tepat dalam penerbit acara domain. Sebagian besar waktu, penangan event domain Anda akan memiliki dependensi dan jika Anda menggunakan wadah IoC, Anda harus memastikan bahwa instance yang tepat disuntikkan. Misalnya, dalam aplikasi web, file[ThreadStatic]atribut bermasalah untuk pelingkupan. Kompleksitas lain adalah batas transkripsional. Anda harus mempertimbangkan transaksi, karena jika suatu entitas memunculkan peristiwa domain, tetapi komit berikutnya ke basis data gagal, semua penangan peristiwa domain akan memerlukan cara untuk mundur, jika tidak, pada akhirnya Anda akan memunculkan peristiwa yang tidak valid. Namun jika Anda memiliki basis-basis ini tercakup, maka peristiwa domain adalah pola yang bagus untuk merangkum logika domain dalam entitas itu sendiri.

Perbedaan antara pendekatan 2 dan 3 tergantung pada use case. Peristiwa domain berlaku ketika Anda ingin memanggil perilaku tambahan sebagai respons terhadap suatu peristiwa, yang dalam bentuk lampau . Ini merupakan kendala penting, karena pengendali peristiwa domain tidak dapat memengaruhi perilaku entitas. Di sisi lain, dengan pendekatan 2, layanan yang disuntikkan memiliki potensi untuk mempengaruhi perilaku karena dinyatakan sebagai ketergantungan untuk perilaku tertentu itu.