Identifikasi batas model domain untuk setiap layanan mikro

Tip

Konten ini adalah kutipan dari eBook, .NET Microservices Architecture for Containerized .NET Applications, tersedia di .NET Docs atau sebagai PDF yang dapat diunduh gratis dan dapat dibaca secara offline.

Unduh PDF

Tujuan saat mengidentifikasi batas dan ukuran model untuk setiap layanan mikro bukan untuk mendapatkan pemisahan yang paling terperinci, meskipun Anda seharusnya mendapatkan layanan mikro kecil jika memungkinkan. Sebagai gantinya, tujuan Anda adalah mendapatkan pemisahan paling bermakna yang dipandu oleh pengetahuan domain Anda. Penekanannya bukan pada ukuran, tetapi pada kemampuan bisnis. Selain itu, jika ada kohesi yang jelas diperlukan untuk area aplikasi tertentu berdasarkan jumlah dependensi yang tinggi, hal tersebut menunjukkan perlunya satu layanan mikro juga. Kohesi adalah cara untuk mengidentifikasi cara memecah atau mengelompokkan layanan mikro. Pada akhirnya, saat Anda mendapatkan lebih banyak pengetahuan tentang domain, Anda harus menyesuaikan ukuran layanan mikro Anda, secara berulang. Menemukan ukuran yang tepat bukan merupakan proses sekali coba.

Sam Newman, promotor layanan mikro yang diakui dan penulis buku Building Microservices, menyoroti bahwa Anda harus merancang layanan mikro Anda berdasarkan pola Konteks yang Dibatasi (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. BC membatasi penerapan model domain dan memberi anggota tim pengembang pemahaman yang jelas dan bersama tentang apa yang harus kohesif dan apa yang dapat dikembangkan secara mandiri. 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 membuat aplikasi. Tetapi, terkadang yang terjadi justru sebaliknya -organisasi perusahaan dibentuk oleh perangkat lunak. Anda mungkin perlu membalikkan hukum Conway dan membangun batas seperti yang Anda inginkan agar perusahaan diatur, condong ke arah konsultasi proses bisnis.

Untuk mengidentifikasi konteks yang dibatasi, Anda dapat menggunakan pola DDD yang disebut Pola Pemetaan Konteks. Dengan Pemetaan Konteks, Anda mengidentifikasi berbagai konteks dalam aplikasi dan batasannya. Merupakan hal yang umum, misalnya, untuk memiliki konteks dan batas yang berbeda untuk setiap subsistem kecil. Peta Konteks adalah cara untuk menentukan dan membuat batas antara domain secara eksplisit. BC bersifat mandiri dan mencakup detail dari satu domain -detail seperti entitas domain- dan menentukan kontrak integrasi dengan BC lain. Ini mirip dengan definisi layanan mikro: layanan mikro mandiri, layanan mikro menerapkan kemampuan domain tertentu, dan layanan mikro harus menyediakan antarmuka. Inilah sebabnya mengapa Pemetaan Konteks dan pola Konteks yang Dibatasi adalah pendekatan yang cocok untuk mengidentifikasi batas model domain dari layanan mikro Anda.

Saat merancang aplikasi besar, Anda akan melihat bagaimana model domain aplikasi besar dapat dipecah - misalnya, ahli domain dari domain katalog akan memberi nama entitas secara berbeda di domain katalog dan inventaris daripada ahli domain pengiriman. Atau entitas domain pengguna mungkin berbeda dalam ukuran dan jumlah atribut ketika berhadapan dengan ahli CRM yang ingin menyimpan setiap detail tentang pelanggan daripada ahli domain pemesanan yang hanya membutuhkan sebagian data 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 menyatukan istilah-istilah tersebut. Sebagai gantinya, terima perbedaan dan kekayaan yang disediakan oleh setiap domain. Jika Anda mencoba untuk memiliki database terpadu untuk seluruh aplikasi, upaya menyatukan kosakata akan menjadi canggung dan tidak akan terdengar tepat untuk salah satu dari beberapa ahli domain. Oleh karena itu, BC (diterapkan sebagai layanan mikro) akan membantu Anda mengklarifikasi tempat Anda dapat menggunakan istilah domain tertentu dan tempat Anda harus membagi sistem dan membuat BC tambahan dengan domain yang berbeda.

Anda akan mengetahui bahwa Anda mendapatkan batas dan ukuran yang tepat untuk setiap BC dan model domain jika Anda memiliki sedikit hubungan kuat antara model domain, dan Anda biasanya tidak perlu menggabungkan informasi dari beberapa model domain saat melakukan operasi aplikasi biasa.

Mungkin jawaban terbaik untuk pertanyaan tentang seberapa besar model domain untuk setiap layanan mikro seharusnya adalah sebagai berikut: model domain harus memiliki BC mandiri, yang terisolasi sebaik mungkin, yang memungkinkan Anda bekerja tanpa harus terus-menerus beralih ke konteks lain (model layanan mikro lain). Pada Gambar 4-10, Anda dapat melihat bagaimana beberapa layanan mikro (beberapa BC) masing-masing memiliki modelnya sendiri dan bagaimana entitas layanan mikro dapat ditentukan, bergantung pada persyaratan spesifik untuk setiap domain yang diidentifikasi dalam aplikasi Anda.

Gambar 4-10. Mengidentifikasi entitas dan batas model layanan mikro

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

Tetapi, Anda mungkin juga memiliki entitas yang memiliki bentuk berbeda tetapi memiliki 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 di layanan mikro Pemesanan, atau yang bernama Pembayar di layanan mikro Pembayaran, dan bahkan yang bernama Pelanggan di layanan mikro Layanan Pelanggan. Ini karena, bergantung pada bahasa di mana pun yang digunakan setiap ahli 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. Tetapi, pengguna yang sama dalam bentuk Pembayar di Pembayaran layanan mikro atau dalam bentuk Pelanggan di Layanan Pelanggan layanan mikro mungkin tidak memerlukan daftar atribut yang sama.

Pendekatan serupa digambarkan pada Gambar 4-11.

Gambar 4-11. Mengurai model data tradisional menjadi beberapa model domain

Saat menguraikan model data tradisional antara konteks yang dibatasi, Anda dapat memiliki entitas berbeda yang memiliki identitas yang sama (pembeli juga merupakan pengguna) dengan atribut yang berbeda di setiap konteks yang dibatasi. 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 atau detail alternatif tentang pengguna saat atribut atau detail sebenarnya merupakan pembeli. Setiap layanan mikro atau BC mungkin tidak memerlukan semua data yang terkait dengan entitas Pengguna, hanya sebagian saja, bergantung pada masalah yang harus dipecahkan atau konteksnya. Misalnya, dalam model layanan mikro Harga, Anda tidak memerlukan alamat atau nama pengguna, cukup ID (sebagai identitas) dan Status, yang akan berdampak pada diskon saat menentukan harga seat setiap pembeli.

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

Pada dasarnya, ada konsep bersama tentang 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 lainnya.

Ada beberapa keuntungan untuk tidak berbagi entitas pengguna yang sama dengan jumlah atribut yang sama di seluruh domain. Salah satu keuntungannya adalah mengurangi duplikasi, sehingga model layanan mikro tidak memiliki data yang tidak dibutuhkan. Keuntungan 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