Model domain bersama antara berbagai layanan microser

Bayangkan skenario dua layanan mikro yang berbeda. Satu untuk menangani Otentikasi dalam layanan, yang lain menangani Manajemen Pengguna. Mereka berdua memiliki konsep Pengguna, dan akan berbicara tentang Pengguna melalui panggilan satu sama lain.

Di manakah model Domain dari "Pengguna" berada? Apakah mereka berdua memiliki representasi yang berbeda tentang apa yang dilakukan Pengguna di tingkat basis data? Bagaimana ketika kita memiliki UserDTO untuk digunakan dalam panggilan API, apakah mereka berdua memiliki satu untuk API masing-masing?

Apa solusi yang diterima umum untuk masalah arsitektur semacam ini?

Dalam arsitektur Microservices, masing-masing benar-benar independen dari yang lain dan harus menyembunyikan detail implementasi internal.

Jika Anda membagikan modelnya, Anda menggabungkan layanan microser dan kehilangan salah satu keuntungan terbesar di mana setiap tim dapat mengembangkan layanan microser tanpa batasan dan kebutuhan untuk mengetahui bagaimana mengembangkan layanan microser lainnya. Ingatlah bahwa Anda bahkan dapat menggunakan bahasa yang berbeda di masing-masing bahasa, ini akan sulit jika Anda mulai memasangkan layanan microser.

Jika mereka terlalu terkait mungkin mereka benar-benar satu seperti kata @uuu.

Pertanyaan-pertanyaan Terkait:

• Mengapa begitu buruk untuk membaca data dari database "dimiliki" oleh microservice yang berbeda
• Bagaimana Anda menangani konsep bersama dalam arsitektur layanan mikro?

Jika dua layanan terjalin cukup sehingga akan merepotkan untuk mengimplementasikannya tanpa berbagi DTO dan objek model lainnya, itu pertanda kuat bahwa Anda seharusnya tidak memiliki dua layanan.

Tentu saja contoh itu tidak masuk akal sebagai dua layanan; sulit membayangkan spesifikasi untuk 'Manajemen pengguna' begitu rumit sehingga akan membuat seluruh tim begitu sibuk sehingga mereka tidak punya waktu untuk melakukan otentikasi.

Jika karena alasan tertentu, maka mereka akan berkomunikasi menggunakan string yang pada dasarnya sewenang-wenang, seperti dalam OAuth 2.0 .

Anda dapat menganggap mereka sebagai dua Konteks Terikat terpisah (dalam bahasa Desain Domain-Driven). Mereka tidak boleh berbagi data apa pun di antara mereka, selain dari ID yang digunakan untuk menghubungkan "Pengguna" konteks Otentikasi dengan "Pengguna" konteks lainnya. Mereka masing-masing dapat memiliki perwakilan mereka sendiri tentang apa "Pengguna" itu, dan model domain mereka sendiri, yang hanya informasi yang diperlukan untuk melakukan tanggung jawab bisnis mereka.

Ingat bahwa model domain tidak mencoba memodelkan "benda" dunia nyata, tetapi benda apa itu dalam konteks tertentu (seperti Manajemen Identitas / Otorisasi, atau Sumber Daya Manusia, dll).

Mereka berdua memiliki konsep Pengguna, dan akan berbicara tentang Pengguna melalui panggilan satu sama lain.

Saya juga setuju dengan apa yang dikatakan @soru. Jika satu layanan membutuhkan data layanan lain, maka batasannya salah.

Solusi yang bagus adalah apa yang muncul dengan @pnschofield - memperlakukan layanan Anda sebagai konteks Terikat.

Berbicara tentang subjek, singkatnya: model domain bersama membunuh otonomi layanan, mengubah sistem layanan mikro Anda menjadi monolit terdistribusi. Yang tampaknya bahkan lebih buruk daripada monolit.

Jadi masih ada pertanyaan umum yang belum terpecahkan - bagaimana mendefinisikan batas layanan atau konteks, sehingga mereka berkembang dalam keterpaduan yang tinggi dan kebaikan kopling yang longgar.

Saya datang dengan solusi untuk memperlakukan konteks saya sebagai kapabilitas bisnis. Ini adalah tanggung jawab bisnis yang lebih tinggi, fungsionalitas bisnis, berkontribusi pada tujuan bisnis secara keseluruhan. Anda dapat menganggapnya sebagai langkah yang harus dilakukan oleh organisasi Anda untuk mendapatkan nilai bisnis.

Urutan langkah khas yang saya ambil saat mengidentifikasi batas layanan adalah sebagai berikut:

1. Identifikasi kemampuan bisnis tingkat tinggi. Biasanya mereka serupa di antara organisasi dari domain yang sama. Anda bisa merasakan seperti apa rasanya memeriksa model rantai nilai Porter .
2. Dalam setiap kemampuan, selami lebih dalam dan identifikasi sub-kemampuan.
3. Perhatikan komunikasi antar kapabilitas. Lihatlah apa yang dilakukan organisasi. Biasanya, komunikasi terkonsentrasi dalam kemampuan, memberi tahu sisanya tentang hasil pekerjaannya. Jadi ketika menerapkan arsitektur teknis, layanan Anda juga harus berkomunikasi melalui acara. Ini memiliki beberapa konsekuensi positif. Dengan pendekatan ini layanan Anda mandiri dan kohesif. Mereka tidak membutuhkan komunikasi yang sinkron dan transaksi terdistribusi.

Mungkin contoh teknik ini akan menarik bagi Anda. Jangan ragu untuk memberi tahu saya apa yang Anda pikirkan, karena saya merasa pendekatan ini sangat menguntungkan. Tentu itu bisa berhasil untuk Anda juga.

Microservice bukan tentang "berbagi apa-apa", tetapi "berbagi sesedikit mungkin". Dalam kebanyakan kasus "Pengguna" adalah entitas yang benar-benar umum (hanya karena Pengguna diidentifikasi oleh beberapa pengenal bersama - userId / email / telepon). Entitas semacam itu dibagikan menurut definisi. Model Pengguna berada di luar cakupan satu layanan microser. Jadi, Anda harus memiliki skema global, di mana Pengguna (hanya bidang yang paling umum) harus ditempatkan. Dalam kasus ketat hanya id.