Domain-Driven Design dan Bounded Contexts
Konsep dasar untuk membangun event-driven arsitektur
Kita sudah sering membaca domain driven design dan bounded context ini dari beberapa penjelasan mengenai microservice arsitektur. Akan tetapi, belum dijelaskan secara khusus pada artikel tersendiri. Untuk itu, saya rasa diperlukan satu artikel yang membahasnya secara khusus.
Domain-driven design (DDD) atau kalau kita diterjemahkan secara bebas sebagai desain berbasis domain, seperti yang dicetuskan oleh Eric Evans pada bukunya yang berjudul sama,memperkenalkan beberapa konsep penting yang diperlukan untuk membuat dan membangun microservice berbasis event.
DDD merupakan sebuah pendekatan untuk mengembangkan software kompleks yang menghubungkan konsep bisnis dengan implementasi teknis secara mendalam. DDD ini bukanlah sebuah metodologi atau teknologi tetapi lebih ke pendekatan secara praktikal dan pendefinisian (terminologi) yang fokus terhadap keputusan desain software dalam hubungannya dengan domain bisnis yang kompleks. DDD ini umumnya digunakan dalam pengembangan software dengan berorientasi object dan pendekatan agile.
Kita coba perjelas pengertian dari bagian DDD ini sebagai berikut.
Domain
Pengertian dari domain seperti yang dijelaskan dalam beberapa buku literatur adalah ruang masalah yang ditempati oleh bisnis yang memberikan solusi. Ini mencakup semua masalah yang dihadapi oleh bisnis, termasuk prospek, ide, pengertian atau terminologi bisnis, dan apapun yang berhubungan dengan ruang masalah tadi.
Pengertian domain ini terlepas dari apakah bisnisnya terkait secara langsung atau tidak. Dengan demikian, domain ini terlepas dari keberadaan bisnis atau bisnisnya berjalan dengan baik atau tidak.
Subdomain
Subdomaian ada bagian atau komponen dari domain utama. Setiap subdomain akan fokus pada bagian tanggung jawab tertentu dan biasanya mencerminkan beberapa struktur organisasi bisnis (contoh gudang, penjualan, dan teknik).
Subdomain dapat dilihat sebagai domain dalam dirinya sendiri (local). Subdomain seperti domain termasuk dalam ruang masalah tadi. Jadi sebenarnya subdomain ada karena memiliki parent domain atau subdomain ini adalah bagian dari domain yang cakupannya lebih luas.
Domain dan Subdomain Model
Domain model adalah pemodelan atau abstraksi dari domain yang sebenarnya untuk keperluan bisnis tentunya. Bagian dan properties dari domain yang paling penting bagi bisnis kita jadikan model.
Model domain utama bisnis dapat dilihat melalui product yang disediakan bisnis untuk pelanggannya. Model domain ini juga berupa antarmuka tempat pelanggan berinteraksi dengan produk dan berbagai proses dan fungsi yang digunakan bisnis untuk memenuhi segala tujuannya.
Model ini seringkali diperlukan untuk disempurnakan saat domain berubah atau saat prioritas bisnis berubah. Model domain ini adalah bagian dari solusi karena merupakan konstruksi yang digunakan bisnis untuk memecahkan masalah.
Ubiquitous Language
Ubiquitous adalah istilah yang di cetuskan oleh Eric Evan dalam DDD untuk membangun bahasa yang umum dan ketat yang di gunakan secara bersama antar developer dan team product. Bahasa ini harus di dasarkan pada domain model yang telah di jelaskan di atas.
Dalam software development tantangan terhebat adalah menerjemahkan keinginan dari customer. Sering sekali customer tidak memahami dan mengetahui dengan benar apa yang mereka butuhkan. Berdasarkan penelitian yang dilakukan pada tahun 2013–2014, dunia software termasuk urutan ke 3 dalam hal ketidakpastian dengan tingkat yang tinggi.
Terlepas dari metodologi atau kerangka yang digunakan, kita melihat masalah ketidakpastian dari sisi miskomunikasi. DDD menyediakan tools untuk menghindari miskomunikasi antara tim bisnis dan tim developer software, yaitu Ubiquitous Language.
Terdapat dua peran penting yang musti ada dalam proses software development. Pertama domain expert, contohnya ahli keuangan atau dokter yang ahli di bidangnya. Kedua adalah software developer yang menerjemahkan model-model yang di buat ke dalam barisan code.
Bounded Context
Bounded context adalah batas-batas logis, termasuk di dalamnya input, output, event (peristiwa), requirements, proses, dan data model yang terdapat hubungannya dengan subdomain. Idealnya bounded context dan subdomain berada dalam keselarasan (alignment) tetapi biasanya legacy sistem, technical debt, dan integrasi dengan pihak ketiga akan membuat pengecualian.
Bounded context juga bagian dari solusi yang memiliki dampak yang besar pada bagaimana service-service dalam microservice akan berkomunikasi satu sama lain.
Pada sistem yang sangat besar kadang terjadi perbedaan pengertian dari istilah-istilah yang digunakan. Bounded Context merupakan sebuah pendekatan yang memisahkan model besar ke dalam konteks kecil secara eksplisit dan hubungan antara keduanya.
Dengan Bounded Context, anda tidak perlu khawatir atas perbedaan kosakata atau perbedaan konsep keilmuan yang dipakai dalam pengembangan software. Misalnya, konsep akuntansi pembukuan dan akuntansi keuangan memiliki kosakata mirip, atau konsep sales dan support memiliki perilaku yang berbeda.
Dalam internal boundex context harus kohesif, intensif, dan terkait erat. Adapun hubungan dengan bounded context lainnya harus longgar (loose coupling). Dengan demikian, di internal kuat di eksternal perubahan di internal tidak berdampak besar bagi yang lainnya.
Bounded Context dan Kebutuhan Bisnis
Biasanya persyaratan bisnis pada suatu produk akan berubah dengan berjalannya waktu. Bisa dikarenakan organisasi yang berubah atau ada permintaan fitur baru. Akan tetapi, jarang perubahan akan implementasi dari suatu produk tanpa ada perubahan persyaratan bisnis. Inilah mengapa kita harus membuat bounded context ini di bangun di sekitar persyareatan bisnis bukannya teknologi.
Menyelaraskan bounded context pada persyaratan bisnis memungkinkan tim untuk membuat perubahan pada implementasi microservice dengan cara yang sangat kohesif dan digabungkan secara longgar. Ini memberi tim otonomi untuk merancang dan mengimplementasikan solusi untuk kebutuhan bisnis spesifik, yang sangat mengurangi ketergantungan antar tim dan memungkinkan setiap tim untuk fokus secara ketat pada persyaratannya sendiri.
Pattern Umum Pada DDD
Pemrograman merupakan kegiatan yang bebas, setiap orang mempunyai style masing-masing. Dalam pekerjaan pengembangan software dengan pendekatan DDD, kita bekerja dalam sebuah tim yang mengharuskan kita untuk mematuhi pola-pola umum sehingga setiap programmer dapat bekerjasama dalam membangun software.
Terdapat pola-pola umum yang digunakan dalam implementasi menggunakan pendekatan DDD dari segi struktur, yaitu Entity, Value Object, Service, dan Aggregate.
Mungkin untuk lebih detail membahas mengenai pattern-pattern yang biasa dipakai pada DDD dapat kita bahas secara tersendiri pada tema Context Mapping dan Clean Code.
Kesimpulan
DDD sangat membantu kita dalam mengembangkan software berskala besar. Apalagi apabila arsitektur yang digunakan adalah microservice atau bahkan lebih jauh lagi adalah event-driven.
Pengembangan software menggunakan pendekatan DDD lebih tepat digunakan untuk aplikasi besar dan tidak disarankan digunakan pada aplikasi kecil. Inti dari DDD adalah fokus terhadap proses bisnis dan maintain proses bisnis tersebut.
Domain Driven Design — YouTube Video
References
- Adam Bellemare. 2020. Building Event-Driven Microservices. USA: O’Reilly Media, Inc.
- Domain-Driven Design Community
- Evans, Eric. 2003. Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison Wesley
- Fowler, Martin. 2006. Bounded Context.
- Domain-specific Language and Tools for Strategic Domain-driven Design, Context Mapping and Bounded Context Modeling
