Dalam DDD, apakah Layanan Domain pada dasarnya hanya Pola Fasad dan / atau Mediator?

Dalam Desain Berbasis Domain, Lapisan Domain dapat memiliki beberapa layanan (tradisional). Misalnya, untuk domain Pengguna, kami mungkin memiliki:

UserFactory, yang membangun objek Pengguna dengan cara yang berbeda
UserRepository, yang bertanggung jawab untuk berinteraksi dengan Layanan Kegigihan di Lapisan Infrastruktur

Apakah Layanan Pengguna dalam Lapisan Domain hanyalah Mediator dan / atau Fasad untuk kedua layanan dan Lapisan Infrastruktur, atau apakah ada yang lebih dari itu?

object-oriented object-oriented-design domain-driven-design

— e_i_pi
sumber

Lihat juga Layanan di DDD dan Layanan di DDD

— Erik Eidt

Saya sudah membaca posting Level Gorodinski, tidak pernah melihat tautan kedua itu. Bacaan yang bagus, pasti menyentuh beberapa poin penting!

— e_i_pi

Jawaban:

Domain services paling baik dijelaskan oleh apa yang bukan mereka:

mereka juga EntitiesbukanAggregate roots
mereka tidak Value objects
membawa pengetahuan domain yang secara alami tidak cocok hanya satu Entity atau satu Value object

Contoh dari a Domain serviceadalah Saga/Process manager: ia mengoordinasikan proses yang berjalan lama yang melibatkan banyak Aggregate roots, mungkin dari yang berbeda Bounded contexts.

Yang sedang berkata, apa itu Domain servicedan bagaimana itu diterapkan adalah dua hal ortogonal.

Apakah Layanan Pengguna dalam Lapisan Domain hanyalah Mediator dan / atau Fasad untuk kedua layanan dan Lapisan Infrastruktur, atau apakah ada yang lebih dari itu?

Beberapa layanan domain seperti UserRepository(terdiri dari antarmuka yang ditentukan dalam Domain layerdan implementasi konkret dalam Infrastructure layer) dapat diimplementasikan menggunakan Facadepola desain. Layanan domain lainnya tidak.

Tidak ada aturan keras tentang bagaimana mengimplementasikannya, selain aturan penting yang Domain layerharus tidak bergantung pada lapisan lain (dan SOLID ).

— Constantin Galbenu
sumber

Terima kasih, saya pikir saya akhirnya mengerti Lapisan Domain. Seiring dengan memegang objek data (Agregat, Entitas dan Nilai Objek) juga memegang aturan bisnis - tetapi bukan implementasi konkret dari aturan tersebut. Layanan Domain menentukan apa yang dapat Anda lakukan untuk objek data Domain, tetapi tidak memiliki pengetahuan tentang bagaimana operasi tersebut berfungsi secara internal.

— e_i_pi

@e_i_pi aturan bisnis hanya dilindungi oleh Agregat dan entitas bersarangnya. Layanan domain tidak terlibat dalam hal ini.

— Constantin Galbenu

@e_i_pi di mana operasi melibatkan lebih dari satu Agregat. Misalnya, mengingat daftar BankAccounts (Agregat) dari Seseorang (Agregat lain), layanan domain akan menghitung total saldo akun-akun tersebut.

— Constantin Galbenu

@ e_i_pi: Saya pikir Anda memiliki beberapa kesalahpahaman. Jadi, seluruh Lapisan Domain adalah model perangkat lunak dari domain Anda. Anda berkata - "Seiring dengan memegang objek data (Agregat, Entitas dan Objek Nilai)" - ini bukan "objek data" dalam arti bahwa mereka hanya menyimpan data; ini benar-benar menerapkan aturan domain, mereka menentukan perilaku. Sekarang, Layanan Domain , menurut Buku DDD oleh E. Evans , adalah aspek-aspek dari domain yang tidak cocok secara alami menjadi objek (entitas atau objek nilai).

— Filip Milovanović

Sebaliknya, Layanan Domain "didefinisikan murni dalam hal apa yang dapat dilakukan untuk klien", didefinisikan dalam hal elemen lain dari model domain (sehingga ia mengatur elemen-elemen tersebut dengan cara apa pun, dan menegakkan aturan domain yang mengatur orkestrasi itu). Layanan domain itu sendiri tidak memiliki kewarganegaraan. Ada juga konsep Layanan Aplikasi , yang berada di lapisan tingkat yang lebih tinggi, dan pada dasarnya mengimplementasikan kisah pengguna, atau menggunakan kasus yang setara, dengan bertindak sebagai antarmuka ke lapisan domain. Perhatikan bahwa rasio objek vs layanan akan bervariasi tergantung pada domain yang dimodelkan.

— Filip Milovanović

Saya melihat layanan di DDD sebagai hasil dari Dependency Inversion .

Jika Anda menggunakan dependensi "biasa", maka kode domain Anda akan memanggil database untuk menyimpan atau meminta entitas, atau pabrik, yang membuat entitas, yang terkait dengan database atau layanan eksternal atau semacam kode infrastruktur lainnya.

Tapi bukan itu seharusnya kode domain. Kode domain tidak boleh bergantung pada kode infrastruktur. Karena ketergantungan ini membuat lebih sulit untuk menguji dan, mungkin, menggunakan kembali. Itulah sebabnya Anda membalikkan ketergantungan itu. Anda membuat kode infrastruktur bergantung pada kode domain. Dan untuk melakukan itu, Anda perlu memperkenalkan abstraksi. Abstraksi yang mendefinisikan perilaku apa yang diharapkan oleh kode domain untuk diterapkan oleh infrastruktur.

Dan layanan dalam DDD adalah abstraksi itu. Dalam sebagian besar kasus, untuk kode domain, layanan tersebut harus berupa antarmuka biasa. Dan implementasinya harus dalam kode infrastruktur, yang memiliki ketergantungan pada antarmuka tersebut.

— Euforia
sumber

Terima kasih atas jawaban Anda, kedua jawaban itu memberi saya "aha!" saat. Saya pikir tanpa jawaban Anda, saya tidak akan sepenuhnya memahami konsep itu, tetapi saya lebih suka jawaban Constantine sebagai indikator untuk pembaca masa depan.

— e_i_pi