# BAB 3: DESAIN STRATEGIS DENGAN SUBDOMAIN **Buku:** Domain-Driven Design Distilled **Penulis:** Vaughn Vernon **Penerjemah:** Everest ERP Architecture Team --- Ketika Anda bekerja pada sebuah proyek DDD, selalu ada beberapa *Bounded Contexts* yang berperan. Salah satu dari *Bounded Contexts* tersebut adalah **Core Domain (Domain Inti)**, dan akan ada juga berbagai **Subdomain** di dalam *Bounded Contexts* lainnya. Pada bab sebelumnya, Anda melihat pentingnya membagi model-model yang berbeda berdasarkan *Ubiquitous Language* spesifik mereka dan membentuk beberapa *Bounded Contexts*. Komposisi pemodelan yang paling optimal yang dicapai tim adalah: **Satu Subdomain per Bounded Context, dan satu Bounded Context per Subdomain (1:1)**. Dengan kata lain, model *Agile Project Management Core* adalah satu *Bounded Context* yang bersih sekaligus satu *Subdomain* yang bersih. Dalam beberapa situasi, mungkin ada beberapa *Subdomain* di dalam satu *Bounded Context*, namun hal tersebut tidak mencapai hasil pemodelan yang paling ideal. --- ### Apa itu Subdomain? (*What Is a Subdomain?*) Secara sederhana, sebuah **Subdomain** adalah bagian (*sub-part*) dari domain bisnis Anda secara keseluruhan. Anda dapat menganggap Subdomain sebagai representasi dari satu model domain logis tunggal. Sebagian besar domain bisnis perusahaan biasanya terlalu besar dan terlalu rumit untuk dipikirkan secara menyeluruh sekaligus, sehingga kita umumnya hanya memusatkan perhatian pada Subdomain-Subdomain yang harus kita gunakan dalam suatu proyek tertentu. Subdomain dapat digunakan untuk memecah seluruh domain bisnis Anda secara logis sehingga Anda dapat memahami ruang masalah (*problem space*) Anda pada proyek yang besar dan kompleks. Cara lain untuk memikirkan Subdomain adalah bahwa ia merupakan **area keahlian yang jelas (*clear area of expertise*)**, dengan asumsi bahwa ia bertanggung jawab untuk memberikan solusi bagi area inti bisnis Anda. Hal ini menyiratkan bahwa Subdomain tertentu akan memiliki satu atau lebih Pakar Domain (*Domain Experts*) yang sangat memahami aspek-aspek bisnis yang difasilitasi oleh Subdomain tersebut. Subdomain juga memiliki signifikansi strategis yang lebih besar atau lebih kecil bagi bisnis Anda. Jika DDD digunakan untuk mengembangkannya sejak awal, Subdomain akan diimplementasikan sebagai *Bounded Context* yang bersih. Pakar Domain yang mengkhususkan diri di area bisnis tersebut akan menjadi anggota tim yang mengembangkan *Bounded Context* tersebut. --- ### Tiga Jenis Subdomain (*Types of Subdomains*) Ada tiga jenis utama Subdomain di dalam sebuah proyek perangkat lunak: #### 1. Core Domain (Domain Inti) Ini adalah area di mana organisasi Anda melakukan **investasi strategis utama** dalam model domain tunggal yang terdefinisi dengan sangat baik. Di sinilah Anda mengerahkan sumber daya yang signifikan untuk menyusun *Ubiquitous Language* secara cermat di dalam sebuah *Bounded Context* yang eksplisit. - *Core Domain* menempati prioritas tertinggi dalam daftar proyek organisasi Anda karena inilah yang akan membedakan perusahaan Anda dari semua pesaing (*competitive differentiator*). - Karena organisasi Anda tidak bisa unggul dalam semua hal yang dilakukannya, *Core Domain* Anda menandai batas di mana perusahaan Anda **wajib unggul**. - Mencapai tingkat pembelajaran dan pemahaman mendalam yang diperlukan untuk membuat keputusan pemodelan ini membutuhkan komitmen, kolaborasi, dan eksperimen yang intensif. #### 2. Supporting Subdomain (Subdomain Pendukung) Ini adalah situasi pemodelan yang membutuhkan **pengembangan kustom (*custom development*)**, karena solusi perangkat lunak siap pakai (*off-the-shelf*) tidak tersedia di pasar. - Meskipun demikian, Anda tetap tidak akan melakukan jenis investasi sebesar yang Anda berikan untuk *Core Domain*. - Anda bahkan dapat mempertimbangkan untuk mengalihdayakan (*outsource*) jenis *Bounded Context* ini kepada pihak ketiga untuk menghindari kesalahan menganggapnya sebagai sesuatu yang membedakan secara strategis dan berinvestasi berlebihan padanya. - Meskipun begitu, ini tetap merupakan model perangkat lunak yang penting, karena *Core Domain* Anda tidak dapat beroperasi dan sukses tanpanya (misalnya: modul pelacak riwayat revisi kustom, format cetak khusus internal). #### 3. Generic Subdomain (Subdomain Generik) Solusi untuk jenis domain ini biasanya **sudah tersedia untuk dibeli di pasar (software jadi/SaaS)**, atau dapat dialihdayakan dengan mudah, atau bahkan dikembangkan secara internal oleh tim pengembang standar. - Berhati-hatilah agar tidak salah mengira *Generic Subdomain* sebagai *Core Domain*. Jangan membuang-buang anggaran dan talenta terbaik Anda di sini. - Contoh: Modul manajemen login & otentikasi user, modul penagihan faktur langganan umum, modul pengiriman notifikasi email/SMS, modul integrasi gateway pembayaran perbankan standar. Ketika kita mendiskusikan proyek di mana DDD diterapkan secara penuh, kita hampir selalu mendiskusikan sebuah **Core Domain**. --- ### Menghadapi Kompleksitas Sistem Warisan (*Dealing with Legacy Complexity*) Beberapa batasan sistem di dalam domain bisnis organisasi kemungkinan besar adalah **sistem warisan (*legacy systems*)**—baik sistem monolitik lama yang pernah dibuat oleh organisasi Anda sendiri bertahun-tahun lalu atau sistem yang dibeli melalui lisensi perangkat lunak pihak ketiga. Pada titik ini Anda mungkin tidak dapat berbuat banyak untuk langsung menghapus atau merombak total sistem warisan tersebut, namun Anda tetap perlu memikirkan dan memperhitungkannya ketika sistem tersebut memiliki dampak pada proyek *Core Domain* baru Anda. Untuk melakukannya, gunakan **Subdomain** sebagai alat untuk mendiskusikan ruang masalah (*problem space*) Anda. Sayangnya, beberapa sistem warisan sangat bertentangan dengan cara DDD merancang *Bounded Contexts*. Anda bahkan dapat menyebut sistem tersebut sebagai **sistem warisan tanpa batas (*unbounded legacy systems*)**. Itu karena sistem warisan seperti itu adalah apa yang telah saya sebut sebagai **Bola Lumpur Raksasa (*Big Ball of Mud*)**. Kenyataannya, satu sistem monolitik tersebut penuh dengan banyak model kusut yang seharusnya dirancang dan diimplementasikan secara terpisah, tetapi malah tercampur baur menjadi satu kekacauan yang sangat rumit dan saling mengunci. #### Strategi Mengurai Monolit Legacy: Ketika kita mendiskusikan sistem warisan lama, sebenarnya ada beberapa—bahkan mungkin banyak—**model domain logis** yang hidup berdampingan di dalam sistem tersebut. Pikirkan setiap model domain logis tersebut sebagai sebuah **Subdomain terpisah**: - Misalnya di dalam satu aplikasi ERP lama yang besar, Anda dapat mengidentifikasi 5 model logis: 1. *Accounts Subdomain* (Akuntansi & Keuangan) 2. *Orders Subdomain* (Pesanan Penjualan) 3. *Catalog Subdomain* (Katalog Produk) 4. *Fulfillment Subdomain* (Gudang & Pengemasan) 5. *Shipping Subdomain* (Pengiriman & Ekspedisi) Memperlakukan Subdomain logis ini sebagai entitas terpisah membantu kita bergulat dengan kompleksitas sistem besar. Ini sangat masuk akal karena memungkinkan kita memperlakukan ruang masalah seolah-olah sistem tersebut telah dikembangkan menggunakan DDD dan beberapa *Bounded Contexts*. Sistem warisan terasa tidak terlalu monolitik dan tidak terlalu "berlumpur" jika kita membayangkan *Ubiquitous Language* yang terpisah, setidaknya demi memahami bagaimana kita harus berintegrasi dengannya. Berpikir dan mendiskusikan sistem warisan semacam itu menggunakan Subdomain membantu kita mengatasi kenyataan pahit dari model yang kusut. Dan saat kita bernalar menggunakan alat ini, kita dapat menentukan Subdomain mana yang lebih berharga bagi bisnis dan diperlukan untuk proyek baru kita, dan mana yang dapat diturunkan ke status yang kurang penting. --- ### Penyelarasan Ideal: 1 Bounded Context = 1 Subdomain Ketika menggunakan DDD, sebuah *Bounded Context* idealnya harus selaras **satu-ke-satu (1:1)** dengan satu *Subdomain*. Artinya, jika ada satu *Bounded Context*, tujuannya adalah ada satu model *Subdomain* di dalam *Bounded Context* tersebut. Hal ini mungkin tidak selalu dapat dicapai dalam setiap situasi praktis, tetapi jika memungkinkan, sangat penting untuk merancang dengan cara tersebut. Ini akan menjaga *Bounded Contexts* Anda tetap bersih dan terfokus pada inisiatif strategis inti. Jika Anda terpaksa harus membuat model kedua di dalam *Bounded Context* yang sama (di dalam *Core Domain* Anda), Anda harus **memisahkan model sekunder tersebut dari Core Domain Anda menggunakan Modul/Paket terpisah (*completely separate Module/Package*)**. Ini membuat pernyataan linguistik yang jelas bahwa satu model adalah inti (*core*) dan model lainnya hanyalah pendukung (*supporting*).