Konteks & Domain Terbatas DDD?

Saya telah bekerja dalam aplikasi yang relatif kompleks dengan 10 tabel database (Agregat, Entitas / Nilai Objek) dan menerapkan DDD. Pada titik ini pada dasarnya tampak DDD-Lite yang berarti bahwa ada Layanan Aplikasi / Domain, Model Domain (Entitas, Nilai Objek), dan Repositori.

Saya mengambil buku Menerapkan DDD dan hal pertama yang ia sebutkan adalah DDD-Lite dan Konteks Terbatas dan Peristiwa Domain hilang sebagai kesalahan pertama yang biasa terjadi ketika memulai DDD.

Saat ini saya sudah mencoba mengatur Model Domain oleh hubungan Agregat, dan menggunakan ruang nama untuk menunjukkannya.

Saya gagal melihat manfaat / kejatuhan terkait pemisahan proyek Model Domain ke dalam konteks Terikat terpisah (belum). Mungkin akan menjadi jelas nanti tapi saya ingin umpan balik kehidupan nyata pada Bounded Contexts (dan mungkin sub domain dll jika mereka mengikat ke dalamnya).

architecture domain-driven-design enterprise-architecture

— lko
sumber

Tampak bagi saya bahwa satu-satunya hal yang mendefinisikan konteks terikat terpisah adalah kebutuhan untuk membedakan linguistik dan perbedaan operasional yang terkait, yaitu disebut produk di satu area dan produk di area lain tetapi mereka berbeda, jadi kami membutuhkan dua produk dan keduanya bisa ' t berada dalam model yang sama (nama yang sama dll). Jadi mengapa kita tidak mengganti saja nama untuk mewakili semantik mereka yang sedikit berbeda? Mereka kita dapat memiliki satu model untuk memerintah mereka semua. Subdomain bersifat alami tetapi saya tidak melihat konteks terbatas saat ini. Hanya berpikir keras di sini ...

— Ashley Aitken

Saya kira Anda sudah menyadari mengapa menguntungkan untuk membagi domain Anda pada konteks. Jadi apa yang bisa berguna sekarang adalah cara yang tepat untuk mengidentifikasi mereka, untuk menentukan batas-batas konteksnya. Inilah cara saya melakukannya: medium.com/@wrong.about/…

— Zapadlo

Jawaban:

Pertimbangkan perusahaan yang memiliki beberapa departemen berbeda:

Pengembangan perangkat lunak
SDM
Akuntansi

Bisakah Anda membuat model pengguna yang secara ekspresif dapat mewakili semua area bisnis itu? Pikirkan seperti apa entitas Pengguna di masing-masing. Mungkin dibagi menjadi tiga entitas yang berbeda:

Pengembang
Karyawan
Penerima pembayaran

Upaya untuk membuat instantiate pengguna dalam setiap konteks sangat berbeda. Mungkin kira-kira seperti ini:

Karyawan baru (ssn, nama, joindate, dateofbirth, gender)
Pengembang baru (Karyawan, workstation, kredensial)
Penerima Pembayaran baru (Karyawan, peran)

maafkan contoh, sulit untuk menggambarkan secara akurat tanpa model domain yang tepat untuk referensi

Jika Anda menggunakan implementasi naif dan menggunakan entitas pengguna tunggal, itu akan berakhir menjadi model data anemia penuh pengambil dan penyetel, karena Anda tidak bisa sepenuhnya mewakili pengguna di semua tempat.

Ada batasan yang jelas dalam bisnis ini, jadi sangat berguna untuk memodelkannya seperti itu. Seorang pengguna yang masuk versus pengguna dalam sistem penggajian versus pengguna yang bermain game semuanya sangat berbeda, bahkan jika mereka adalah bagian dari sistem besar yang sama.

Berpikir dengan cara lain - Anda sekarang dapat membuat kode manajemen pengembang Anda menjadi sangat ringan dan independen dari sisa sistem Anda. Itu dapat menggunakan tipe yang lebih akurat dengan sedikit bagasi yang perlu dikhawatirkan. Ini adalah langkah untuk membangun subsistem yang lebih kecil yang pada akhirnya dapat diekstraksi ke dalam aplikasinya sendiri.

— Adrian Schneider
sumber

Terima kasih atas contoh pendukung yang membantu menggambarkan berbagai kebutuhan 3 SM.

— lko

Bukan cara saya terbiasa melihat konsep-konsep ini: biasanya, an Employeebukan a User, ia memiliki a User. Ini Userhanyalah sebuah entitas di mana seseorang dapat login dan mengakses satu atau lebih aplikasi di dalam organisasi. Dan Employeetidak selalu memiliki User. Selain itu, Anda biasanya tidak mendapatkan aplikasi sederhana untuk berbagai departemen; biasanya, setiap departemen memiliki aplikasi sendiri, masing-masing berisi model domainnya sendiri. Jadi, bagi saya jawaban ini tidak membantu mengklarifikasi kebutuhan untuk memiliki konteks terikat terpisah dalam basis kode yang sama.

— Rogério

@ Rogério keberatan Anda sebenarnya adalah contoh yang indah tentang mengapa penting untuk mendefinisikan dengan benar bahasa mana pun yang digunakan di dalam setiap konteks yang dibatasi :)

— MauganRa

Saya hanya ingin tahu dalam kasus-kasus ketika kita memiliki sistem manajemen pelanggan, ketika kita menelepon untuk menanyakan pesanan kita, atau penagihan, dll. Kita ditahan sementara kita ditransfer ke departemen yang sesuai. Pengetahuan domain dari masing-masing departemen ikut berperan - sangat mengganggu pelanggan dalam skenario ini. Mungkin kita bisa menyalahkan DDD karena memaksa pemisahan antara konteks ini.

— Andez

Saya bisa memberi Anda contoh lain. Anggap Anda memiliki beberapa sistem e-niaga. Anda akan memiliki produk di sana, namun produk akan menjadi bagian dari setidaknya dua domain berbeda:

Katalog produk, tempat Anda menyimpan deskripsi produk dan semua atribut Anda
Persediaan, di mana Anda memiliki tingkat stok produk

Jika Anda memiliki satu konteks terbatas untuk kedua domain, solusi Anda dapat dengan cepat menjadi bola lumpur besar karena Anda akan mulai referensi silang itu. Pada akhirnya Anda tidak akan memiliki dua domain lagi. Inventaris produk Anda akan dimanjakan dengan referensi katalog produk dan sebaliknya. Karena ini, Anda tidak akan dapat mengubah satu domain tanpa menyentuh yang lain meskipun Anda sepenuhnya menyadari ini tidak diperlukan. Model Anda menjadi tergantung satu sama lain dan sangat erat, dan tergantung dengan cara yang buruk - tergantung pada implementasi.

Namun, jika Anda memiliki dua konteks terikat, semua perubahan yang Anda lakukan dalam satu domain tidak akan memengaruhi yang lain segera setelah Anda menjaga saluran komunikasi tetap jelas. Ini berarti Anda harus memiliki duplikasi data tetapi ini adalah biaya paling murah untuk membayar aplikasi berbasis komponen yang salah. Domain Anda dapat berbicara satu sama lain menggunakan peristiwa domain. Bahkan jika Anda tidak berencana untuk memiliki aplikasi berbasis SOA di awal, Anda akan dapat meningkatkan ke tingkat itu ketika Anda perlu dengan usaha yang relatif rendah karena Anda hanya mengubah transportasi untuk acara domain Anda, meninggalkan ide di baliknya tetap utuh.

Pembaruan: Ada siaran keterampilan yang bagus tentang SkillsMatter, dari Eric Evans. Dia memberikan analogi cerita lama, ketika beberapa orang buta menggambarkan seekor gajah dari sudut pandang mereka. Karena setiap manusia hanya dapat menyentuh sebagian dari gajah, mereka menggambarkannya sebagai "pohon", "dinding", "ular", "tali". Dan masing-masing pria itu benar dalam konteksnya. Konteks terikat adalah tempat tinggal bahasa di mana-mana. Di luar konteks, istilah-istilah ini mungkin memiliki makna yang sangat berbeda tetapi di dalam konteksnya, bahasanya sama di berbagai domain. Greg Young sangat menyarankan untuk mulai membaca buku biru dari bab 11, karena konsep paling penting dan mendasar dijelaskan di sana. Fokus pada pola taktis di awal buku membuat pendekatan "DDD-light" ini sangat umum,

— Alexey Zimarev
sumber

+1 untuk juga memunculkan duplikasi. itu agak membingungkan pada awalnya ("Apakah saya melakukan ini salah ?!) tapi itu benar-benar alami, dalam banyak kasus, diperlukan.

— Adrian Schneider

Dalam skenario ini, apakah Productkelas - kelas ini keduanya secara hipotetis berbagi ID yang sama (mis. Kedua tabel BC terpisah memiliki kunci asing ke tabel dengan ID Produk tunggal)? Mungkin saat berkomunikasi dengan Acara Domain mereka dapat menggunakan ID itu?

— lko

Itu semua tergantung pada penyimpanan apa yang dipilih. Tidak perlu menggunakan id teknis untuk merujuk lintas-domain. Juga tidak disarankan untuk melakukan komunikasi lintas konteks.

— Alexey Zimarev

Sepertinya sudah waktunya untuk mengeluarkan buku biru dari rak dan membaca bab

— Markus Pscheidt