Menggunakan analisis domain untuk memodelkan layanan mikro
Salah satu tantangan terbesar dari layanan mikro adalah untuk menentukan batas-batas layanan individu. Aturan umum adalah bahwa layanan harus melakukan "satu hal" - tetapi menerapkan aturan itu membutuhkan pemikiran yang cermat. Tidak ada proses mekanis yang akan menghasilkan desain "benar". Anda harus memikirkan secara mendalam tentang domain bisnis, persyaratan, karakteristik arsitektur Anda (juga dikenal sebagai persyaratan non-fungsi), dan tujuan. Jika tidak, Anda dapat berakhir dengan desain serampangan yang menunjukkan beberapa karakteristik yang tidak diinginkan, seperti ketergantungan tersembunyi antara layanan, kopling ketat, atau antarmuka yang dirancang dengan buruk. Artikel ini menunjukkan pendekatan berbasis domain untuk merancang layanan mikro. Mengevaluasi batas layanan adalah upaya berkelanjutan dalam mengembangkan beban kerja. Terkadang evaluasi menghasilkan definisi yang ditentukan ulang dari batas yang ada yang memerlukan pengembangan aplikasi tambahan untuk mengakomodasi perubahan.
Artikel ini menggunakan layanan pengiriman drone sebagai contoh berjalan. Anda dapat membaca selengkapnya tentang skenario dan implementasi referensi yang sesuai di sini.
Pendahuluan
Layanan mikro harus dirancang di sekitar kemampuan bisnis, bukan lapisan horizontal seperti akses data atau pesan. Selain itu, mereka harus memiliki kopling longgar dan kohesi fungsional tinggi. Layanan mikro diikat secara longgar jika Anda dapat mengubah satu layanan tanpa memerlukan layanan lain untuk diperbarui pada saat yang sama. Layanan mikro bersifat kohesif jika memiliki satu tujuan yang terdefinisi dengan baik, seperti mengelola akun pengguna atau melacak riwayat pengiriman. Layanan harus merangkum pengetahuan domain dan abstrak pengetahuan itu dari klien. Misalnya, klien harus dapat menjadwalkan drone tanpa mengetahui detail algoritma penjadwalan atau bagaimana armada drone dikelola. Karakteristik arsitektur harus didefinisikan agar setiap layanan mikro sesuai dengan kekhawatiran domainnya, daripada didefinisikan untuk seluruh sistem. Misalnya, layanan mikro yang menghadap pelanggan mungkin perlu memiliki performa, ketersediaan, toleransi kesalahan, keamanan, keterujian, dan kelincahan. Layanan mikro backend mungkin hanya perlu memiliki toleransi dan keamanan kesalahan. Jika layanan mikro memiliki komunikasi sinkron satu sama lain, dependensi di antara mereka sering menghasilkan kebutuhan untuk berbagi karakteristik arsitektur yang sama.
Desain berbasis domain (DDD) menyediakan kerangka kerja yang dapat memberi Anda sebagian besar jalan menuju serangkaian layanan mikro yang dirancang dengan baik. DDD memiliki dua fase yang berbeda, strategis dan taktis. Dalam DDD strategis, Anda mendefinisikan struktur skala besar sistem. DDD Strategis membantu memastikan bahwa arsitektur Anda tetap fokus pada kemampuan bisnis. DDD Taktis menyediakan sekumpulan pola desain yang dapat Anda gunakan untuk membuat model domain. Pola ini mencakup entitas, agregat, dan layanan domain. Pola taktis ini akan membantu Anda merancang layanan mikro yang digabungkan secara longgar dan kohesif.
Pada artikel ini dan berikutnya, kita akan berjalan melalui langkah-langkah berikut, menerapkannya ke aplikasi Pengiriman Drone:
Mulailah dengan menganalisis domain bisnis untuk memahami persyaratan fungsional aplikasi. Output dari langkah ini adalah deskripsi informal dari domain, yang dapat disempurnakan menjadi serangkaian model domain yang lebih formal.
Selanjutnya, tentukan konteks domain yang dibatasi. Setiap konteks terikat berisi model domain yang mewakili subdomain tertentu dari aplikasi yang lebih besar.
Dalam konteks yang terikat, terapkan pola DDD taktis untuk menentukan entitas, agregat, dan layanan domain.
Gunakan hasil dari langkah sebelumnya untuk mengidentifikasi layanan mikro dalam aplikasi Anda.
Pada artikel ini, kami membahas tiga langkah pertama, yang terutama berkaitan dengan DDD. Pada artikel berikutnya, kami akan mengidentifikasi layanan mikro. Namun, penting untuk diingat bahwa DDD adalah proses yang berulang dan berkelanjutan. Batas layanan tidak ditetapkan dalam batu. Seiring berkembangnya aplikasi, Anda dapat memutuskan untuk memecah layanan menjadi beberapa layanan yang lebih kecil.
Catatan
Artikel ini tidak menunjukkan analisis domain yang lengkap dan komprehensif. Kami sengaja membuat contoh singkat untuk mengilustrasikan poin-poin utama. Untuk latar belakang lebih lanjut tentang DDD, kami merekomendasikanDomain-Driven Design, buku yang ditulis oleh Eric Evans yang pertama kali memperkenalkan istilah tersebut. Referensi bagus lainnya adalah Implementing Domain-Driven Design oleh Vaughn Vernon.
Skenario: Pengiriman drone
Fabrikam, Inc memulai layanan pengiriman drone. Perusahaan ini mengelola armada pesawat drone. Bisnis mendaftar dengan layanan, dan pengguna dapat meminta drone untuk mengambil barang untuk pengiriman. Ketika pelanggan menjadwalkan penjemputan, sistem backend menetapkan drone dan memberi tahu pengguna dengan perkiraan waktu pengiriman. Saat pengiriman sedang berlangsung, pelanggan dapat melacak lokasi drone, dengan ETA yang terus diperbarui.
Skenario ini melibatkan domain yang cukup rumit. Beberapa masalah bisnis termasuk penjadwalan drone, melacak paket, mengelola akun pengguna, dan menyimpan serta menganalisis data historis. Selain itu, Fabrikam ingin masuk ke pasar dengan cepat, lalu melakukan iterasi dengan cepat, menambahkan fungsionalitas dan kemampuan baru. Aplikasi ini perlu beroperasi pada skala cloud, dengan tujuan tingkat layanan (SLO) yang tinggi. Fabrikam juga mengharapkan bahwa bagian yang berbeda dari sistem akan memiliki persyaratan yang sangat berbeda untuk penyimpanan data dan pembuatan kueri. Semua pertimbangan ini menyebabkan Fabrikam memilih arsitektur layanan mikro untuk aplikasi Pengiriman Drone.
Menganalisis domain
Menggunakan pendekatan DDD akan membantu Anda merancang layanan mikro sehingga setiap layanan membentuk kecocokan alami dengan persyaratan bisnis fungsional. Hal tersebut dapat membantu Anda menghindari perangkap membiarkan batas-batas organisasi atau pilihan teknologi mendikte desain Anda.
Sebelum menulis kode apa pun, Anda memerlukan pandangan mata burung tentang sistem yang Anda buat. DDD dimulai dengan memodelkan domain bisnis dan membuat model domain. Model domain adalah model abstrak dari domain bisnis. Hal ini menyaring dan mengatur pengetahuan domain, dan menyediakan bahasa umum bagi pengembang dan ahli domain.
Mulailah dengan memetakan semua fungsi bisnis dan koneksinya. Ini kemungkinan akan menjadi upaya kolaboratif yang melibatkan pakar domain, arsitek perangkat lunak, dan pemangku kepentingan lainnya. Anda tidak perlu menggunakan formalisme tertentu. Buat sketsa diagram atau gambar di papan tulis.
Saat Anda mengisi diagram, Anda mungkin mulai mengidentifikasi subdomain diskrit. Fungsi mana yang terkait erat? Fungsi mana yang menjadi inti bisnis, dan mana yang menyediakan layanan tambahan? Apa grafik dependensinya? Selama fase awal ini, Anda tidak berhubungan dengan teknologi atau detail implementasi. Hal tersebut berarti, Anda harus mencatat tempat di mana aplikasi perlu berintegrasi dengan sistem eksternal, seperti CRM, pemrosesan pembayaran, atau sistem penagihan.
Contoh: Aplikasi pengiriman drone
Setelah beberapa analisis domain awal, tim Fabrikam datang dengan sketsa kasar yang menggambarkan domain Pengiriman Drone.
- Pengiriman ditempatkan di tengah diagram, karena hal tersebut merupakan inti dari bisnis. Segala sesuatu yang lain dalam diagram ada untuk mengaktifkan fungsi ini.
- Manajemen drone juga merupakan inti dari bisnis. Fungsionalitas yang terkait erat dengan manajemen drone termasuk perbaikan drone dan menggunakan analisis prediktif untuk memprediksi kapan drone membutuhkan servis dan pemeliharaan.
- Analisis ETA memberikan perkiraan waktu untuk pengambilan dan pengiriman.
- Transportasi pihak ketiga akan memungkinkan aplikasi untuk menjadwalkan metode transportasi alternatif jika paket tidak dapat dikirim sepenuhnya oleh drone.
- Berbagi drone adalah kemungkinan perpanjangan dari bisnis inti. Perusahaan mungkin memiliki kapasitas drone berlebih selama jam-jam tertentu, dan dapat menyewa drone yang seharusnya menganggur. Fitur ini tidak akan ada di rilis awal.
- Pengawasan video adalah area lain yang mungkin diperluas perusahaan nanti.
- Akun pengguna, Faktur, dan Call center adalah subdomain yang mendukung bisnis inti.
Perhatikan bahwa pada titik ini dalam proses, kami belum membuat keputusan tentang penerapan atau teknologi. Beberapa subsistem mungkin melibatkan sistem perangkat lunak eksternal atau layanan pihak ketiga. Meski begitu, aplikasi perlu berinteraksi dengan sistem dan layanan ini, jadi penting untuk memasukkannya ke dalam model domain.
Catatan
Ketika aplikasi bergantung pada sistem eksternal, ada risiko bahwa skema data atau API sistem eksternal akan bocor ke aplikasi Anda, yang pada akhirnya mengorbankan desain arsitektur. Hal ini terutama berlaku dengan sistem warisan yang mungkin tidak mengikuti praktik terbaik modern, dan dapat menggunakan skema data berbelit-belit atau API usang. Dalam hal ini, penting untuk memiliki batas yang terdefinisi dengan baik antara sistem eksternal ini dan aplikasi. Pertimbangkan untuk menggunakan pola Strangler Fig atau pola Lapisan Anti-Kerusakan untuk tujuan ini.
Tentukan konteks terikat
Model domain akan mencakup representasi dari hal-hal nyata di dunia - pengguna, drone, paket, dan sebagainya. Tetapi itu tidak berarti bahwa setiap bagian dari sistem perlu menggunakan representasi yang sama untuk hal yang sama.
Misalnya, subsistem yang menangani perbaikan drone dan analisis prediktif perlu mewakili banyak karakteristik fisik drone, seperti riwayat pemeliharaan, jarak tempuh, usia, jumlah model, karakteristik performa, dan sebagainya. Tetapi ketika tiba waktunya untuk menjadwalkan pengiriman, kita tidak peduli dengan hal-hal itu. Subsistem penjadwalan hanya perlu tahu apakah drone tersedia, dan ETA untuk pengambilan dan pengiriman.
Jika kita mencoba membuat model tunggal untuk kedua subsistem ini, itu tidak perlu rumit. Ini juga akan menjadi lebih sulit bagi model untuk berkembang dari waktu ke waktu, karena setiap perubahan perlu memuaskan beberapa tim yang bekerja pada subsistem terpisah. Oleh karena itu, seringkali lebih baik untuk merancang model terpisah yang mewakili entitas dunia nyata yang sama (dalam hal ini, drone) dalam dua konteks yang berbeda. Setiap model hanya berisi fitur dan atribut yang relevan dalam konteks khususnya.
Di sinilah konsep DDD dari konteks terikat mulai dimainkan. Konteks yang terikat hanyalah batas dalam domain di mana model domain tertentu berlaku. Melihat diagram sebelumnya, kita dapat mengelompokkan fungsionalitas berdasarkan dengan apakah berbagai fungsi akan berbagi model domain tunggal.
Konteks terikat tidak selalu terisolasi satu sama lain. Dalam diagram ini, garis padat yang menyambungkan konteks terbatas mewakili tempat-tempat di mana dua konteks terbatas berinteraksi. Misalnya, Pengiriman bergantung pada Akun Pengguna untuk mendapatkan informasi tentang pelanggan, dan pada Manajemen Drone untuk menjadwalkan drone dari armada.
Dalam buku Domain Driven Design, Eric Evans menjelaskan beberapa pola untuk menjaga integritas model domain ketika berinteraksi dengan konteks terbatas lainnya. Salah satu prinsip utama layanan mikro adalah bahwa layanan berkomunikasi melalui API yang terdefinisi dengan baik. Pendekatan ini sesuai dengan dua pola yang Evans sebut Open Host Service dan Published Language. Ide dari Open Host Service adalah bahwa subsistem mendefinisikan protokol formal (API) untuk subsistem lain untuk berkomunikasi dengannya. Bahasa yang diterbitkan memperluas ide ini dengan menerbitkan API dalam bentuk yang dapat digunakan tim lain untuk menulis klien. Dalam artikel Merancang API untuk layanan mikro, kita membahas penggunaan Spesifikasi OpenAPI (sebelumnya dikenal sebagai Swagger) untuk menentukan deskripsi antarmuka bahasa-agnostik untuk REST API, yang dinyatakan dalam format JSON atau YAML.
Selama sisa perjalanan ini, kami akan fokus pada konteks batas Pengiriman.
Langkah berikutnya
Setelah menyelesaikan analisis domain, langkah selanjutnya adalah menerapkan DDD taktis, untuk menentukan model domain Anda dengan lebih presisi.