Mengintegrasikan Bounded Contexts
Meski disebut bounded, konteks-konteks yang berbeda, meskipun penyebutannya, tidak boleh jalan sendiri-sendiri: mereka harus saling berinteraksi untuk mencapai tujuan sistem secara keseluruhan. Interaksi itu diwujudkan lewat kontrak, titik temu di mana satu konteks menggunakan output dari konteks lain.
Tergantung pada hubungan tim pengembangnya, DDD mengenalkan beberapa pola integrasi bounded context:
Partnership (Kerjasama Dua Arah): Dua tim berkolaborasi erat, saling bantu menyesuaikan antarmuka jika dibutuhkan. Tidak ada pihak yang memaksakan modelnya; setiap perubahan disepakati atau dinegosiasikan bersama. Pola ini memerlukan komunikasi intensif dan mungkin Continuous Integration agar tiap perubahan cepat diuji bersama.
Shared Kernel: Dua atau lebih bounded context berbagi sebagian model yang sama (misalnya model otorisasi pengguna). Perubahan di bagian bersama (kernel) langsung memengaruhi semua konteks. Oleh karena itu, hanya fitur inti yang benar-benar perlu yang sebaiknya digabungkan di sini, biasanya berupa kontrak integrasi atau struktur data bersama. Untuk implementasi, kode bersama bisa diletakkan di satu modul yang di-link oleh setiap konteks. Setiap perubahan mesti diuji secara lintas-konteks agar tidak ada yang rusak.
Kelompok berikutnya adalah Customer–Supplier, hubungan satu arah dengan tim penyuplai (supplier) dan tim pelanggan (customer):
Conformist: Tim supplier mendikte modelnya dan tim pelanggan mengikuti begitu saja. Misalnya, jika API yang disediakan rekanan sudah baku, tim kita mungkin cuma mengonsumsi mentah-mentah data itu tanpa negosiasi. Pola ini tidak memerlukan adaptasi besar; tim pelanggan menerima persyaratan supplier seperti adanya. Biasanya cocok untuk model standar industri yang cukup baik dan tidak ingin diubah.
Anticorruption Layer (ACL), Jika tim supplier berkuasa penuh, tetapi modelnya tidak cocok atau sering berubah (misal sistem warisan dengan schema kacau), tim pelanggan bisa membuat lapisan perantara (translator) yang menerjemahkan model supplier ke model sendiri. Misalnya, jika subdomain kita termasuk inti yang rumit, kita tidak mau ikut-ikutan merusak modelnya. Atau jika kontrak sering berubah, ACL menjaga agar perubahan itu hanya mengganggu translator, bukan seluruh sistemnya. Intinya, ACL mengisolasi konteks kita dari istilah asing dan membuat model kita lebih bersih sesuai kebutuhan.
Open-Host Service: Kebalikan dari ACL, di sini supplier melindungi pelanggannya. Supplier membuat model publik (published language) yang nyaman bagi konsumen, lalu menjembatani model internalnya ke model publik tersebut. Dengan begitu, supplier dapat mengubah model internalnya tanpa mengganggu konsumen, asalkan masih menerjemahkannya ke bahasa publik yang sudah ditetapkan. Pola ini sering digunakan jika supplier ingin memberi layanan yang stabil bagi banyak konsumen sekaligus.
Terakhir, ada pola Separate Ways, dua tim memutuskan tidak berkolaborasi sama sekali. Ini bukan ideal, tapi bisa terjadi karena berbagai alasan. Misalnya, jika komunikasi antar tim sangat sulit (pemisahan geografis atau politik internal), lebih murah menyalin fungsionalitas di kedua sisi daripada memaksakan integrasi. Atau jika yang ingin dibagikan adalah subdomain generik (seperti logging, notifikasi, dll), mungkin lebih simpel setiap tim melokalkan solusinya sendiri daripada bikin satu layanan terpusat. Juga, jika model di kedua sisi benar-benar berbeda sehingga ACL atau Conformist menjadi mahal atau tidak mungkin, tim bisa memilih Duplicate (Separate Ways).
Peringatan: pola ini tidak boleh dipakai untuk subdomain inti perusahaan, karena menyalin inti bisnis berarti merugi, kita kehilangan optimasi dan konsistensi yang seharusnya menjadi sumber keunggulan.
Setelah semua hubungan integrasi ini terdefinisi, kita dapat menggambarnya dalam context map, peta visual bounded context beserta tipe integrasi antaranya. Context map ini memberikan wawasan strategis tinggi: apa saja komponen besar sistem, siapa bermitra dengan siapa, siapa yang mandiri atau bahkan memisahkan diri, dan pola komunikasi seperti apa yang terjadi antar tim.
Misalnya, sebuah panah ‘anticorruption layer’ dari tim A ke B menunjukkan tim A memakai ACL terhadap tim B. Context map sebaiknya disusun sejak awal proyek dan terus diperbarui bersama tim – misalnya setiap tim bertanggung jawab menjaga gambaran integrasi kontekstualnya tetap up-to-date.
Diulang kembali secara singkat, berikut pola-pola utama integrasi bounded context dalam DDD (Khononov, 2022):
Partnership: Integrasi ad hoc dengan komunikasi dua arah.
Shared Kernel: Dua konteks berbagi potongan model yang konsisten.
Conformist: Konsumen menyesuaikan diri dengan model penyedia layanan.
Anticorruption Layer: Konsumen membuat lapisan penerjemah agar model penyedia tidak merusak model internalnya.
Open-Host Service: Penyedia menyiapkan antarmuka publik agar konsumennya nyaman, sementara detail internal tetap fleksibel.
Separate Ways: Dua tim bekerja terpisah, setiap konteks menduplikasi kebutuhan umum agar integrasi tidak diperlukan.
Peta konteks (context map) menggambarkan semua ini secara keseluruhan. Dengan memahami pola-pola integrasi ini, kita dapat menyelaraskan desain teknis dengan struktur organisasi dan strategi bisnis yang ada.
Referensi
Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.