Haruskah saya meletakkan logika perhitungan di Entitas atau di Lapisan Bisnis?

Baru-baru ini saya dihadapkan pada pertanyaan apakah penghitungan sederhana harus diletakkan di lapisan Entity, atau haruskah Entity murni untuk hanya menyimpan data mentah dan meninggalkan logika perhitungan di lapisan bisnis.

Jadi pertanyaan saya adalah apakah masuk akal untuk merangkum perhitungan sederhana dalam properti dalam kelas entitas?

design-patterns

— Kata
sumber

Tergantung pada jenis arsitektur yang Anda inginkan.

Dalam Desain Berbasis Domain, Anda akan membuat Model Domain yang memiliki data dan fungsionalitas.

Ini berarti bahwa Ordermemiliki properti (atau metode) yang akan mengembalikan harga total pesanan berdasarkan OrderLines. Itu Orderjuga akan memiliki metode AddOrderItem(Product product, int amount)dan Orderakan memeriksa apakah sudah ada OrderLineuntuk produk tertentu.

Dalam model seperti itu Anda juga akan memiliki objek yang bukan entitas nyata, seperti Repositoryuntuk mengakses data atau Factoryuntuk membuat entitas. Ini disebut Layanan Domain. Layer Aplikasi bertanggung jawab untuk memanggil Layanan Domain (misalnya untuk mengambil entitas dari database) dan kemudian akan menjalankan fungsionalitas pada entitas. The Application Layerharus setipis mungkin.

Ini adalah artikel yang bagus tentang DDD yang menjelaskan konsep-konsep ini secara lebih rinci.

Anda juga dapat menggunakan Model Domain Anemik . Itu berarti bahwa entitas Anda terdiri dari properti get / set dan tidak mengandung perilaku. Dalam desain seperti itu, Lapisan Bisnis Anda akan berisi perilaku, seperti menghitung Orderharga dan memeriksa duplikat OrderLines.

Ada beberapa pendapat yang berbeda apakah Model Domain Anemik adalah hal yang buruk. Secara pribadi saya lebih suka Model Domain nyata.

Artikel ini menjelaskan perbedaan antara Model Domain Anemic dan non-Anemic.

— Wouter de Kort
sumber

Hai Wouter, terima kasih atas jawabannya dan tautannya. Saya tampaknya menghadapi pola pikir yang salah bahwa ketika menggunakan model domain Anemic, semua logika bisnis (bahkan yang sangat sederhana) harus dimasukkan ke dalam lapisan bisnis. Ini tampaknya tidak masuk akal dalam beberapa kasus di mana logika bisnis benar-benar hanya bergantung pada model itu sendiri. Misalnya, properti dihitung dari properti yang ada dalam model. Saya tidak dapat menemukan alasan yang masuk akal untuk menempatkan logika bisnis yang semuanya tergantung pada model itu sendiri ke dalam lapisan bisnis.

Dalam model domain anemik, karena kami memiliki kelas bisnis dan entitas, bagaimana memberi nama kelas dengan benar untuk menghindari kebingungan di antara mereka? Apakah Anda menyarankan menggunakan sufiks? Jika ya, bisakah Anda memberi contoh?

— Kwadz

Untuk DDD, bagaimana jika logika perhitungan harga rumit? Misalnya, harga didasarkan pada lokasi (pajak), info pengguna (diskon tanggal lahir, diskon keanggotaan), kupon, kartu kredit (diskon khusus kartu kredit), dll. Bagaimana kita dapat memasukkan logika tersebut ke dalam Orderkelas?

— Sher10ck

Agregat pesanan Anda harus berisi semua informasi yang diperlukan untuk melakukan perhitungan. Karena berdasarkan uraian Anda, ini sebenarnya bagian dari agregat. Tetapi jika logika menjadi sangat kompleks dan Anda mungkin perlu mengubahnya, maka saya akan meneruskan kalkulator sebagai objek ke konstruktor entitas dan membiarkan entitas menggunakan kalkulator secara internal untuk menetapkan harga.

— burzum

Anemia ... domain yang buruk terdengar seolah-olah menderita semacam penyakit. Bukankah Anda lebih suka Didorong? Ya!

— Matt Jenkins

Ya, Entitas dan Objek bisnis hampir sama, hampir sepanjang waktu. Misalnya jika Anda memiliki kelas produk dan Anda ingin mengekspos properti yang mengambil beberapa properti yang ada di kelas produk dan melakukan perhitungan lalu memaparkannya. Tidak masalah dalam istilah itu, logika menciptakan properti itu tetap ada di kelas.

Sekarang, pertanyaan mungkin datang, di mana sesuai dengan kelas lapisan bisnis Anda. Saya lebih suka menggunakan kelas lapisan bisnis yang memiliki beberapa logika untuk menangani masalah bisnis. Misalnya dalam contoh Produk Anda, masalah bisnis dapat menagih uang menggunakan vendor pihak ketiga seperti paypal.

Satu hal kunci untuk diingat adalah Entitas akan selalu memiliki identitas tetapi objek bisnis adalah entitas tanpa identifikasi. Misalnya produk adalah entitas tetapi uang tidak akan memiliki identitas. 1000 contoh uang berbeda akan sama.

Iya. Jika semua logika bisnis properti bergantung pada properti yang ada pada model yang sama, akan lebih baik jika hanya menambahkan properti dalam model. Ini akan membantu menghilangkan pasangan yang tidak perlu dengan lapisan bisnis untuk properti yang dihitung.