Mengidentifikasi batas model domain untuk setiap layanan mikro

Petunjuk / Saran

Konten ini adalah kutipan dari eBook, Arsitektur Layanan Mikro .NET untuk Aplikasi .NET Kontainer, tersedia di .NET Docs atau sebagai PDF gratis yang dapat diunduh yang dapat dibaca secara offline.

Unduh PDF

Tujuan dalam mengidentifikasi batas dan ukuran model untuk setiap layanan mikro bukan untuk mencapai pemisahan paling rinci, meskipun Anda sebaiknya condong menuju layanan mikro kecil jika memungkinkan. Sebaliknya, tujuan Anda harus mencapai pemisahan yang paling bermakna yang dituntun oleh pemahaman Anda tentang domain. Penekanannya tidak pada ukurannya, tetapi sebaliknya pada kemampuan bisnis. Selain itu, jika ada kohesi yang jelas yang diperlukan untuk area aplikasi tertentu berdasarkan jumlah dependensi yang tinggi, yang menunjukkan kebutuhan akan satu layanan mikro juga. Kohesi adalah cara untuk mengidentifikasi cara memecah atau mengelompokkan layanan mikro bersama-sama. Pada akhirnya, meskipun Anda mendapatkan lebih banyak pengetahuan tentang domain, Anda harus menyesuaikan ukuran layanan mikro Anda, secara berulang. Menemukan ukuran yang tepat bukanlah proses satu bidikan.

Sam Newman, promotor layanan mikro yang diakui dan penulis buku Building Microservices, menyoroti bahwa Anda harus merancang layanan mikro Anda berdasarkan pola Bounded Context (BC) (bagian dari desain berbasis domain), seperti yang diperkenalkan sebelumnya. Terkadang, BC dapat terdiri dari beberapa layanan fisik, tetapi tidak sebaliknya.

Model domain dengan entitas domain tertentu berlaku dalam BC konkret atau layanan mikro. Batasan Konteks memisahkan penerapan model domain dan memberi anggota tim pengembang pemahaman yang jelas dan bersama tentang apa yang harus kohesif dan apa yang dapat dikembangkan secara independen. Ini adalah tujuan yang sama untuk layanan mikro.

Alat lain yang menginformasikan pilihan desain Anda adalah hukum Conway, yang menyatakan bahwa aplikasi akan mencerminkan batas sosial organisasi yang memproduksinya. Tetapi terkadang sebaliknya adalah benar -the organisasi perusahaan dibentuk oleh perangkat lunak. Anda mungkin perlu membalikkan hukum Conway dan merancang batasan sesuai dengan cara Anda ingin organisasi perusahaan dibentuk, dengan memasukkan prinsip konsultasi proses bisnis.

Untuk mengidentifikasi konteks terikat, Anda dapat menggunakan pola DDD yang disebut pola Pemetaan Konteks. Dengan Pemetaan Konteks, Anda mengidentifikasi berbagai konteks dalam aplikasi dan batas-batasnya. Biasanya memiliki konteks dan batas yang berbeda untuk setiap subsistem kecil, misalnya. Peta Konteks adalah cara untuk menentukan dan membuat batas-batas tersebut secara eksplisit di antara domain. BC bersifat otonom dan mencakup detail domain tunggal -details seperti entitas domain dan menetapkan kontrak integrasi dengan BC lainnya. Ini mirip dengan definisi layanan mikro: ini otonom, mengimplementasikan kemampuan domain tertentu, dan harus menyediakan antarmuka. Inilah sebabnya mengapa Pemetaan Konteks dan pola Konteks Terikat adalah pendekatan yang baik untuk mengidentifikasi batas model domain layanan mikro Anda.

Saat merancang aplikasi besar, Anda akan melihat bagaimana model domainnya dapat difragmentasi - pakar domain dari domain katalog akan memberi nama entitas secara berbeda di katalog dan domain inventaris daripada pakar domain pengiriman, misalnya. Atau entitas domain pengguna mungkin berbeda dalam ukuran dan jumlah atribut saat berhadapan dengan pakar CRM yang ingin menyimpan setiap detail tentang pelanggan daripada untuk ahli domain pemesanan yang hanya membutuhkan data parsial tentang pelanggan. Sangat sulit untuk membedakan semua istilah domain di semua domain yang terkait dengan aplikasi besar. Tetapi yang paling penting adalah Anda tidak boleh mencoba untuk menyatukan persyaratan. Sebagai gantinya, terima perbedaan dan kekayaan yang disediakan oleh setiap domain. Jika Anda mencoba memiliki basis data yang terpadu untuk seluruh aplikasi, upaya untuk menyatukan kosakata akan terasa tidak efektif dan tidak sesuai dengan pendapat beberapa ahli dari berbagai domain. Oleh karena itu, BC (diimplementasikan sebagai layanan mikro) akan membantu Anda mengklarifikasi di mana Anda dapat menggunakan istilah domain tertentu dan di mana Anda harus membagi sistem dan membuat BC tambahan dengan domain yang berbeda.

Anda akan tahu bahwa Anda mendapatkan batasan dan ukuran yang tepat dari setiap Bounded Context (BC) dan model domain jika Anda memiliki sedikit keterkaitan yang kuat antara model-domain, dan Anda biasanya tidak perlu menggabungkan informasi dari beberapa model domain saat melakukan operasi aplikasi yang umum.

Mungkin jawaban terbaik untuk pertanyaan tentang seberapa besar model domain untuk setiap layanan mikro adalah sebagai berikut: harus memiliki Bounded Context (BC) yang otonom, yang diisolasi sejauh mungkin, sehingga memungkinkan Anda untuk bekerja tanpa harus terus-menerus beralih ke konteks lain (model layanan mikro lainnya). Pada Gambar 4-10, Anda dapat melihat bagaimana beberapa layanan mikro (beberapa BC) masing-masing memiliki modelnya sendiri dan bagaimana entitasnya dapat ditentukan, tergantung pada persyaratan khusus untuk setiap domain yang diidentifikasi dalam aplikasi Anda.

Gambar 4-10 Mengidentifikasi entitas dan batas model layanan mikro

Gambar 4-10 mengilustrasikan skenario sampel yang terkait dengan sistem manajemen konferensi online. Entitas yang sama muncul sebagai "Pengguna", "Pembeli", "Pembayar", dan "Pelanggan" bergantung pada konteks tertentu. Anda telah mengidentifikasi beberapa BC yang dapat diimplementasikan sebagai layanan mikro, berdasarkan domain yang didefinisikan oleh pakar domain untuk Anda. Seperti yang Anda lihat, ada entitas yang hadir hanya dalam satu model layanan mikro, seperti Pembayaran dalam layanan mikro Pembayaran. Itu akan mudah diimplementasikan.

Namun, Anda mungkin juga memiliki entitas yang memiliki bentuk berbeda tetapi berbagi identitas yang sama di beberapa model domain dari beberapa layanan mikro. Misalnya, entitas Pengguna diidentifikasi dalam layanan mikro Manajemen Konferensi. Pengguna yang sama, dengan identitas yang sama, adalah yang bernama Pembeli dalam layanan mikro Pemesanan, atau yang bernama Payer dalam layanan mikro Pembayaran, dan bahkan yang bernama Pelanggan dalam layanan mikro Layanan Pelanggan. Ini karena, tergantung pada bahasa umum yang digunakan oleh setiap pakar domain, pengguna mungkin memiliki perspektif yang berbeda bahkan dengan atribut yang berbeda. Entitas pengguna dalam model layanan mikro bernama Manajemen Konferensi mungkin memiliki sebagian besar atribut data pribadinya. Namun, pengguna yang sama dalam bentuk Payer dalam layanan mikro Pembayaran atau dalam bentuk Pelanggan dalam layanan mikro Layanan Pelanggan mungkin tidak memerlukan daftar atribut yang sama.

Pendekatan serupa diilustrasikan dalam Gambar 4-11.

Gambar 4-11. Menguraikan model data tradisional ke dalam beberapa model domain

Saat menguraikan model data tradisional antara konteks terikat, Anda dapat memiliki entitas berbeda yang berbagi identitas yang sama (pembeli juga merupakan pengguna) dengan atribut yang berbeda di setiap konteks terikat. Anda dapat melihat bagaimana pengguna hadir dalam model layanan mikro Manajemen Konferensi sebagai entitas Pengguna dan juga hadir dalam bentuk entitas Pembeli di layanan mikro Harga, dengan atribut alternatif atau detail tentang pengguna ketika sebenarnya adalah pembeli. Setiap layanan mikro atau SM mungkin tidak memerlukan semua data yang terkait dengan entitas Pengguna, hanya bagian darinya, tergantung pada masalah yang harus diselesaikan atau konteksnya. Misalnya, dalam model layanan mikro Harga, Anda tidak memerlukan alamat atau nama pengguna, hanya ID (sebagai identitas) dan Status, yang akan berdampak pada diskon saat memberi harga kursi per pembeli.

Entitas Seat memiliki nama yang sama tetapi atribut yang berbeda di setiap model domain. Namun, Seat berbagi identitas berdasarkan ID yang sama, seperti yang terjadi pada Pengguna dan Pembeli.

Pada dasarnya, ada konsep bersama pengguna yang ada di beberapa layanan (domain), yang semuanya berbagi identitas pengguna tersebut. Tetapi di setiap model domain mungkin ada detail tambahan atau berbeda tentang entitas pengguna. Oleh karena itu, perlu ada cara untuk memetakan entitas pengguna dari satu domain (layanan mikro) ke domain lain.

Ada beberapa manfaat untuk tidak berbagi entitas pengguna yang sama dengan jumlah atribut yang sama di seluruh domain. Salah satu manfaatnya adalah mengurangi duplikasi, sehingga model layanan mikro tidak memiliki data apa pun yang tidak mereka butuhkan. Manfaat lain adalah memiliki layanan mikro utama yang memiliki jenis data tertentu per entitas sehingga pembaruan dan kueri untuk jenis data tersebut hanya didorong oleh layanan mikro tersebut.

SebelumnyaBerikutnya