Cara mendefinisikan dengan jelas batas-batas konteks yang dibatasi

Setelah sekitar satu bulan membaca dan meneliti DDD, saya memutuskan untuk memulai proyek saya sendiri dan menciptakan DDD dengan konteks terbatas ini>

• Klien
• Produk
• Pesanan
• Penagihan

Setiap konteks terikat memiliki API lainnya sebagai lapisan presentasi, lapisan domain, lapisan persisten.

Sejauh ini bagus, kodenya berjalan mulus, tetapi datang dari dunia monolitik, saya masih mencoba mencari tahu yang berikut:

• ketika saya ingin membuat klien baru, mengeluarkan faktur baru, membuat pesanan baru saya ingin misalnya mengakses daftar negara. Apakah saya:

a) membuat daftar negara di setiap BC

b) membuat Negara BC -> API dan menggunakannya untuk mendapatkan daftar negara yang tersedia

c) menggunakan API pihak ke-3 dan menarik data melalui lapisan anti korupsi di setiap BC

• ketika mengintegrasikan dengan API pihak ke-3 menggunakan lapisan anti-korupsi atau lapisan adaptor, data apa yang harus disertakan dalam model domain saya? Misalnya jika saya ingin mengintegrasikan API zendesk dengan BC Klien. Apakah saya hanya perlu ticketID di domain saya, atau saya harus mengekstrak semua data dari Zendesk yang ingin saya akses dan gunakan di dalam BC Klien?

Jika aplikasi MVC saya benar-benar mendapatkan data dari API (lapisan presentasi konteks terbatas saya), saya merasa sangat sulit untuk mendefinisikan dengan jelas batas-batas setiap BC. Apakah itu berarti bahwa BC yang dirancang dengan baik akan melayani pengontrol MVC tunggal tanpa perlu mengkonsumsi API tambahan?

Jika konteks terikat Anda yang berbeda memahami arti / tujuan suatu negara secara berbeda, maka Anda perlu memodelkannya secara berbeda di masing-masing negara. Namun, jika kita berbicara hanya tentang data referensi kode dan nama ISO, maka saya percaya itu cukup adil dan standar untuk menyimpannya di tempat yang nyaman dan membuatnya dapat diakses oleh semua pihak yang berkepentingan. Misalnya: database, file konfigurasi, layanan web, dll.

Saya juga ingin melihat model Anda sedikit. Potongan-potongan yang telah Anda daftarkan bisa jadi "entitas" dalam satu "konteks terbatas", tergantung pada struktur perusahaan. BCs seringkali berakhir di sekitar area / departemen / tim yang berbeda, karena itu sering merupakan batas alami antara "bahasa yang ada di mana-mana". Jadi sebagai contoh, alih-alih Penjualan / Produk / Pesanan, saya berharap BC akan sejalan dengan Penjualan / Manufaktur / Pergudangan.

Di dalam BC itu, Anda tidak fokus pada kata benda. Anda fokus pada use case, dan membuat model dari kata benda yang dapat memenuhi use case. Metode pada "root agregat" mengeksekusi kasus penggunaan dan membuat perubahan yang sesuai untuk model terkait.

... semua model salah, tetapi beberapa berguna.

Juga ingat bahwa masing-masing BC dapat menggunakan sistem atau arsitektur yang sama sekali berbeda. BC yang diberikan mungkin tidak pantas menggunakan "komponen perangkat lunak DDD" sama sekali, dan kebanyakan dari mereka mungkin tidak. DDD lebih sedikit tentang komponen perangkat lunak preskriptif dan lebih banyak tentang proses mendesain perangkat lunak. Intinya adalah fokus pada pemahaman konteks perusahaan yang terbatas, memetakan bahasa masing-masing konteks, dan memodelkan kode untuk konteks itu menggunakan bahasa mereka di mana-mana. Dengan begitu ketika Anda berinteraksi dengan pemegang pasak dan merujuk pada kode, kedengarannya bagi mereka seperti Anda berbicara dalam istilah bisnis yang mereka pahami. Dan mengakui bahwa kata yang sama memiliki arti berbeda di SM berbeda.

Ada pola spesifik yang dihasilkan oleh DDD (misalnya repositori, pelapisan spesifik, dll.) Yang berarti untuk mencapai tujuan. Tetapi pola-pola ini tidak dijamin menjadi pola terbaik untuk setiap kasus, bahkan dalam DDD. Sama seperti DDD bukan "" jawaban untuk setiap proyek. Anda hanya perlu melakukan apa yang disarankan analisis Anda adalah hal yang paling praktis untuk dilakukan.

Dari pertanyaan Anda, saya pikir Anda salah paham konteks terbatas. Anda mungkin ingin membaca ulang Bab 14 dari buku biru .

Mencoba menjawab secara umum - Anda harus berhati-hati dalam berbagi konsep antara dua konteks yang berbeda. Bagaimanapun, bagian dari alasan bahwa batas itu ada adalah karena bahasa di mana-mana berubah. Mengasumsikan bahwa data yang sama (dan representasi yang sama) dari suatu entitas dapat digunakan dalam kedua konteks adalah naif - itu mungkin benar, mungkin salah, tetapi tidak ada cara yang baik bagi kita di luar, tanpa akses kepada pakar domain Anda, untuk menilai.

Misalnya, dalam domain klien, "negara" dapat dikaitkan dengan tempat tinggal atau kewarganegaraan. Dalam penagihan, mungkin terkait dengan nilai tukar mata uang. Di beberapa domain itu, Anda mungkin perlu khawatir tentang tarif dan sejenisnya.

Pertanyaan kedua yang perlu Anda ajukan adalah model mana dari Anda yang merupakan buku catatan untuk data "yang dibagikan". Dalam kasus "negara", jawaban yang tepat mungkin adalah tidak satupun dari mereka! Topologi geopolitik tidak dikendalikan oleh model Anda.

Apa yang seharusnya terjadi dalam model domain Anda ketika suatu negara ditempati oleh kekuatan asing?

Ingatlah; banyak dari kita yang terbiasa berpikir tentang struktur data; apa hubungan antara satu bagian data dengan yang lainnya. Dan itu bagus ketika Anda mempertimbangkan laporan, dan berusaha memastikan bahwa semua data yang Anda butuhkan telah dikumpulkan oleh solusi Anda. Tetapi model domain tidak hanya tentang struktur, tetapi tentang perubahan. Anda perlu menaruh perhatian Anda pada bagian itu juga, dan pastikan bahwa Anda memahami dengan baik bagaimana data membatasi perubahan (dan bagaimana kendala tersebut bervariasi dari satu konteks terbatas ke berikutnya).

Konsep yang Anda sebutkan (Klien, Produk, Pesanan, Penagihan) biasanya diwakili dalam Model Domain tunggal dan karenanya Bounded Context. Saya sarankan Anda salah memahami konsep-konsep ini.

Pandangan saya tentang subjek ini adalah untuk mendefinisikan konteks terbatas menggunakan pemetaan kemampuan bisnis atau teknik serupa lainnya seperti analisis rantai nilai. Turun ke langkah-langkah berikut:

1. Tetapkan tanggung jawab tingkat tinggi sistem Anda, atau kemampuan bisnis. Cara terbaik untuk melakukannya menurut saya adalah menyulap dengan langkah-langkah yang dilalui perusahaan Anda untuk mendapatkan nilai bisnis. Batas logis yang Anda buat adalah layanan bisnis Anda, atau, jika Anda suka, konteks terikat.
2. Menggali lebih dalam dalam setiap layanan.
3. Identifikasi komunikasi antara layanan Anda di samping dua poin pertama.

Jadi fokus awalnya adalah bagaimana bisnis Anda beroperasi.

Beberapa saran praktis:

1. Jika salah satu konteks / layanan / etc Anda memerlukan beberapa data konteks lain, kemungkinan besar batasan Anda salah.
2. Cara komunikasi konteks yang sangat diinginkan adalah berbasis peristiwa. Ini adalah kunci skalabilitas dan keandalan. Jika Anda membutuhkan komunikasi yang sinkron, kemungkinan besar batas Anda salah. Selain itu, komunikasi yang sinkron akan mematikan sistem Anda.
3. Domain Anda pada akhirnya lebih konsisten daripada yang Anda pikirkan. Sama seperti milik semua orang. Jangan mencoba untuk membuat semuanya konsisten 100%. Tidak ada arti praktis dalam hal itu.
4. Konteks tidak perlu diatur. Mereka mandiri. Seperti manusia.

Dengan pendekatan ini Anda berakhir dengan layanan yang sangat otonom, dapat dipertahankan, dan dapat diandalkan. Anda mungkin ingin memeriksa contoh mendefinisikan batas konteks.