Bagaimana itu masuk akal?
Jawaban singkat: tidak .
Jawaban yang lebih panjang: pola kelas berat untuk mengembangkan model domain tidak berlaku untuk bagian-bagian solusi Anda yang hanya berupa basis data.
Udi Dahan memiliki pengamatan menarik yang dapat membantu memperjelas ini
Dahan menganggap bahwa suatu layanan harus memiliki semacam fungsi dan beberapa data. Jika tidak memiliki data, maka itu hanyalah sebuah fungsi. Jika semua yang dilakukannya adalah melakukan operasi CRUD pada data, maka itu adalah basis data.
Maksud dari model domain, bagaimanapun, adalah untuk memastikan bahwa semua pembaruan pada data mempertahankan invarian bisnis saat ini. Atau, dengan kata lain, model domain bertanggung jawab untuk memastikan bahwa database yang bertindak sebagai sistem catatan sudah benar.
Ketika Anda berhadapan dengan sistem CRUD, Anda biasanya bukan sistem catatan untuk data. Dunia nyata adalah buku catatan, dan basis data Anda hanyalah representasi cache lokal dari dunia nyata.
Misalnya, sebagian besar informasi yang muncul di profil pengguna, seperti alamat email, atau nomor identifikasi yang dikeluarkan pemerintah, memiliki sumber kebenaran yang hidup di luar bisnis Anda - itu adalah administrator surat orang lain yang menetapkan dan mencabut alamat email, bukan aplikasi Anda. Ini adalah pemerintah yang menetapkan SSN, bukan aplikasi Anda.
Jadi Anda biasanya tidak akan melakukan validasi domain pada data yang datang kepada Anda dari dunia luar; Anda mungkin memiliki pemeriksaan untuk memastikan bahwa data terbentuk dengan baik dan disanitasi dengan baik ; tetapi ini bukan data Anda - model domain Anda tidak mendapatkan veto.
Dalam pendekatan DDD menggunakan lapisan, sepertinya operasi CRUD melewati lapisan domain. tetapi setidaknya dalam kasus kami, ini sepertinya tidak masuk akal.
Itu tepat untuk kasus di mana database adalah buku catatan .
Ouarzy mengatakannya begini .
Bekerja pada banyak kode lawas, saya mengamati kesalahan umum untuk mengidentifikasi apa yang ada di dalam domain, dan apa yang ada di luar.
Aplikasi dapat dianggap CRUD hanya jika tidak ada logika bisnis di sekitar model data. Bahkan dalam kasus (jarang) ini, model data Anda bukan model domain Anda. Ini hanya berarti bahwa, karena tidak ada logika bisnis yang terlibat, kami tidak memerlukan abstraksi untuk mengelolanya, dan dengan demikian kami tidak memiliki model domain.
Kami menggunakan model domain untuk mengelola data yang berada di dalam domain; data dari luar domain sudah dikelola di tempat lain - kami hanya menyalin salinan.
Greg Young menggunakan sistem gudang sebagai ilustrasi utama solusi di mana buku catatan berada di tempat lain (yaitu: lantai gudang). Implementasi yang ia gambarkan sangat mirip dengan Anda - satu basis data logis untuk menangkap pesan yang diterima dari gudang, dan kemudian basis data logis terpisah yang menyimpan kesimpulan yang diambil dari analisis pesan tersebut.
Jadi mungkin kita memiliki dua konteks terbatas di sini? Masing - masing dengan model yang berbeda untukinvestment account
Mungkin. Saya enggan menandainya sebagai konteks terbatas, karena tidak jelas bagasi apa yang disertakan. Mungkin Anda memiliki dua konteks, mungkin satu konteks dengan perbedaan halus dalam bahasa di mana-mana yang belum Anda ambil.
Kemungkinan uji lakmus: berapa banyak pakar domain yang Anda perlukan dua pakar domain untuk membahas spektrum ini, atau hanya satu yang berbicara tentang komponen dengan cara yang berbeda. Pada dasarnya, Anda mungkin bisa menebak berapa banyak konteks terikat yang Anda miliki dengan menerapkan hukum Conway ke belakang.
Jika Anda mempertimbangkan konteks terikat untuk disejajarkan dengan layanan, mungkin lebih mudah: apakah Anda dapat menggunakan dua fungsi ini secara mandiri? Ya menyarankan dua konteks yang dibatasi; tetapi jika mereka perlu terus disinkronkan, maka mungkin itu hanya satu.
