DDD - Apakah model domain anemia merupakan antipattern? Haruskah kita menggunakan model domain kaya? [Tutup]

Model domain anemia telah lama dikritik oleh Evans dan Fowler , karena tampaknya bertentangan dengan prinsip-prinsip berorientasi objek, dll. Komunitas DDD jelas selaras dengan pernyataan ini.

Namun, dalam beberapa tahun terakhir telah ada suara-suara yang tidak setuju yang mengklaim itu bukan anti-perpindahan sama sekali dan itu adalah contoh dari mengikuti prinsip-prinsip SOLID.

Saya telah bekerja bertahun-tahun menggunakan Spring Framework. Setiap proyek di setiap perusahaan selalu memiliki lapisan layanan yang berisi logika bisnis, menggunakan repositori yang beroperasi pada model anemia (entitas JPA). Selain itu, sebagian besar sampel, bahkan yang resmi dari Spring guys, memamerkan cara kerja ini.

Pertanyaan saya adalah: apakah model domain anemia masih dianggap sebagai antipattern? Apakah kita semua melakukan hal-hal (mengenai DDD) yang salah? Tidakkah Anda berpikir bahwa memiliki model Rich Domain melanggar prinsip SOLID?

ADM adalah pola yang baik untuk solusi layanan terdistribusi seperti layanan-mikro. Ini cocok dengan banyak kasus bisnis berbasis web saat ini.

Pertimbangkan jika kita memiliki objek Domain Pesanan. Dengan pendekatan OOP kami akan menambahkan Order.Purchase () Order.Cancel () dll. Ini akan bekerja dengan baik di aplikasi desktop, di mana kami menyimpan pesanan di memori dan melakukan beberapa hal pada contoh yang sama.

Tetapi jika kita memiliki sistem terdistribusi, dengan program yang hanya untuk satu hal, yaitu mengakses daftar pesanan dan membeli masing-masing secara bergantian, atau mendapatkan daftar pesanan dan membatalkan masing-masing secara bergantian kemudian memiliki kedua Metode pada objek yang sama membuat tidak ada merasakan. Kami harus memiliki dua Domain atau Konteks Terbatas:

PurchaseSystemOrder.Purchase()

dan

CancelSystemOrder.Cancel();

Satu-satunya benda yang akan dibagikan benda-benda ini adalah struktur data properti.

Ketika Anda menambahkan lebih banyak dan lebih banyak layanan microser, Anda berakhir dengan puluhan jenis Order. Tidak lagi masuk akal untuk berbicara tentang sebuah Orde sebagai objek Domain, meskipun yang tatanan konseptual yang sama yang sedang diproses oleh semua sistem ini.

Jauh lebih masuk akal untuk memiliki model Anemik, Pesanan, yang hanya merangkum data saja dan mengubah nama layanan Anda sesuai:

PurchaseService.Purchase(Order order)

Sekarang kita dapat membicarakan Order lagi dan kita dapat menambahkan layanan baru apa pun yang kita pikirkan untuk diproses, tanpa memengaruhi layanan lain yang saat ini digunakan.

Fowler and Co berasal dari latar belakang sistem monolith, di dunia mereka pendekatan ADM akan berarti aplikasi tunggal dengan semua layanan terpisah ini dipakai dalam memori dan OrderDTO diedarkan dan dimutasi. Ini akan jauh lebih buruk daripada menempatkan metode pada model Orde kaya.

Tetapi dalam sistem terdistribusi, ada banyak program, masing-masing hanya membutuhkan metode Pesanan tunggal dan menjalankannya pada beberapa pesanan, memuat masing-masing, menjalankan metode dan kemudian membuangnya. Hanya membutuhkan Layanan tunggal dan aliran objek data.

Mengisi model kaya sepenuhnya, khawatir tentang persyaratan dan dependensi dari semua Metode hanya untuk memanggil satu dan kemudian membuang objek segera adalah sia-sia.

Ditambah perubahan ke salah satu metode akan memerlukan memperbarui semua komponen yang didistribusikan karena mereka semua bergantung pada Model Kaya untuk logika mereka.

Saya tidak punya ruang di basis kode saya untuk hal-hal yang tidak mereka butuhkan

SOLID dan DDD saling ortogonal satu sama lain, artinya mereka benar-benar pergi ke arah yang berbeda satu sama lain. Anda seharusnya tidak mengatakan bahwa yang satu digunakan untuk mengesampingkan yang lain, karena mereka bisa dan mungkin harus ada bersama dalam basis kode yang sama.

Model domain anemia hanya menjadi anti-pola setelah domain masalah Anda memiliki banyak perilaku dan Anda memiliki ratusan metode layanan dengan banyak logika atau ketergantungan yang disalin-salin di mana metode lapisan layanan harus memanggil metode lapisan layanan lainnya untuk menyelesaikan sesuatu.

DDD adalah paradigma yang sangat baik untuk layanan mikro karena konsep konteks terbatas .

Waspadai godaan untuk melihat kode infrastruktur sebagai bagian dari domain Anda. Kode infrastruktur adalah segala sesuatu yang tidak Anda tulis sendiri atau apa pun yang digabungkan ke kerangka kerja atau pustaka yang berinteraksi dengan sistem pihak ketiga. Koneksi basis data, mailer SMTP, perpustakaan ORM, waktu menjalankan server aplikasi, semua itu adalah infrastruktur dan Anda tidak boleh memasukkan atau bergantung padanya di domain Anda jika Anda bisa menghindarinya.

Prinsip SOLID adalah seperangkat konsep OOP tujuan umum yang dapat Anda gunakan untuk membuat kode OOP yang lebih baik. Anda dapat menulis basis kode DDD yang baik dengan menggunakannya.

Domain yang kaya bagus jika dilakukan dengan baik. Mimpi buruk saat tidak. Domain anemia selalu buruk. Tapi itu jenis nyaman yang akrab buruk.

Jika Anda hanya menginginkan domain anemik, Anda memilih bahasa yang salah saat memilih bahasa tujuan umum. Bahasa generasi ke-4 berspesialisasi dalam penggunaan khusus. Jika anemia cukup baik menggunakan mereka akan membuat hidup Anda lebih mudah.

Banyak kerangka kerja menyusup ke ruang bahasa sampai Anda tidak dapat mengiklankan pekerjaan sebagai pekerjaan java lagi. Ini pekerjaan Java / Spring. Apa yang mereka lakukan, selain membuat Anda bergantung pada mereka, adalah mengubah bahasa tujuan umum menjadi bentuk bajingan dari bahasa generasi ke-4.

Apakah itu praktik terbaik atau anti-pola? Nah bos Anda kebanyakan hanya peduli apakah Anda dapat mempekerjakan orang untuk bekerja pada basis kode. Jadi, jika kita harus berpura-pura menggunakan bahasa tujuan umum untuk mempekerjakan orang, kita akan melakukannya.

Jika Anda setuju dengan itu maka baik-baik saja. Anda tentu bukan satu-satunya.

Tapi jangan bilang begitulah seharusnya. Jangan bilang itu melakukan apa pun untuk saya lebih dari itu. Saya tahu bagaimana hidup tanpa itu. Saya tahu cara mendorongnya sehingga hanya beberapa hal yang bergantung padanya. Jika Anda meminta saya untuk menyerah dan membiarkannya mengambil alih segalanya hanya karena berjuang itu sulit maka ya saya pikir itu buruk.

Saya tidak punya ruang di basis kode untuk hal-hal yang tidak perlu.

Adapun SOLID dan prinsip-prinsip desain lainnya saya sebagian besar dapat mengikuti mereka bahkan dalam domain anemia. Tidak mengikutinya menyebabkan masalah yang berbeda.