Communication Patterns untuk Menyatukan Bahasa di Dunia yang Berbeda

Setelah kita membangun domain model yang kuat dan melindunginya dengan arsitektur yang rapi, kini muncul pertanyaan baru:

“Bagaimana kalau model kita harus berkomunikasi dengan model dari tim lain?”

Dalam organisasi besar, setiap tim biasanya bekerja di bounded context yang berbeda, masing-masing dengan bahasa, istilah, dan prioritasnya sendiri. Tantangannya adalah bagaimana bounded context ini bisa saling berbicara tanpa saling merusak model satu sama lain.

Di sinilah communication patterns dalam DDD berperan. Ia membantu kita menjembatani dunia yang berbeda, agar integrasi antar sistem tidak membuat domain model kita rusak atau kehilangan makna.

Mengapa Komunikasi Itu Rumit

Komunikasi antara bounded context bukan sekadar “kirim data lewat API”. Masalah sebenarnya bukan di teknologinya, tapi di perbedaan makna.

Bayangkan dua tim:

• Tim Sales menggunakan istilah “Customer” untuk siapa pun yang pernah melakukan transaksi.

• Tim Support menyebut “Customer” hanya untuk pengguna aktif yang punya kontrak dukungan.

Ketika kedua sistem bertukar data tentang Customer, data itu mungkin valid secara teknis, tapi salah makna secara bisnis. Itulah mengapa DDD menekankan bahwa komunikasi antar bounded context harus punya kontrak yang jelas, baik secara teknis maupun semantik.

Hubungan Upstream dan Downstream

Dalam DDD, hubungan antar bounded context digambarkan seperti aliran sungai:

• Upstream → konteks yang mengirim data atau keputusan,

• Downstream → konteks yang menerima dan menyesuaikan diri dengan upstream.

Hubungan ini penting karena menentukan arah pengaruh, siapa yang memengaruhi siapa.

Contoh sederhana

Misalnya ada dua tim:

• Team Orders mengelola pemesanan pelanggan.

• Team Shipping mengurus pengiriman barang.

Ketika pesanan dikonfirmasi, Orders mengirim event ke Shipping untuk memulai proses pengiriman.

Orders (upstream) ---> Shipping (downstream)

Jika tim Orders mengubah format event tanpa koordinasi, tim Shipping akan terkena dampaknya. Jadi, downstream selalu lebih sensitif terhadap perubahan upstream. Inilah mengapa kita perlu communication pattern yang tepat, untuk mengatur dinamika semacam ini.

Pola-Pola Komunikasi antar Context

DDD memperkenalkan beberapa pola utama untuk menggambarkan cara bounded context saling berinteraksi. Masing-masing mencerminkan tingkat kolaborasi dan kekuasaan yang berbeda.

1. Partnership

Dalam Partnership, dua tim bekerja sangat erat, mereka berbagi tujuan dan menegosiasikan setiap perubahan bersama.

Mereka bisa dianggap “sekutu” yang membangun solusi bersama, dengan jadwal rilis dan kontrak yang disepakati dua arah.

“Changes are negotiated together.” — Vlad Khononov (2022)

Pola ini cocok bila dua sistem bergantung kuat satu sama lain dan punya siklus hidup yang sinkron. Misalnya antara tim “Billing” dan “Subscription” di platform SaaS.

Tantangannya: koordinasi butuh komunikasi intensif, jadi lebih cocok untuk organisasi kecil atau modul yang sangat terintegrasi.

2. Customer–Supplier

Dalam pola ini, supplier menyediakan data atau layanan yang digunakan oleh customer. Supplier biasanya memiliki kekuasaan lebih besar karena menentukan struktur data dan kontrak API.

“When the supplier has the power.” — Khononov (2022)

Jika tim supplier berubah, tim customer harus menyesuaikan diri.

Untuk melindungi domain model-nya sendiri, tim customer bisa membuat Anticorruption Layer (ACL), lapisan penerjemah antara model supplier dan model internalnya.

Contoh:

// Model dari supplier (mungkin dari API eksternal)
struct ExternalOrder {
    order_id: String,
    value: f64,
}

// Model internal di domain kita
struct InternalOrder {
    id: u64,
    total: f64,
}

// Anticorruption Layer (penerjemah)
impl From<ExternalOrder> for InternalOrder {
    fn from(eo: ExternalOrder) -> Self {
        InternalOrder { id: eo.order_id.parse().unwrap(), total: eo.value }
    }
}

ACL memastikan model domain kita tidak terkontaminasi oleh model pihak lain. Domain kita tetap bersih, meskipun harus berinteraksi dengan dunia luar.

3. Conformist

Kadang, tim downstream tidak punya pilihan selain menyesuaikan diri sepenuhnya dengan upstream, baik format data, struktur model, maupun jadwal rilisnya.

Inilah pola Conformist. Pola ini sering muncul saat:

• Sistem upstream adalah produk eksternal atau pihak ketiga.

• Atau tim downstream terlalu kecil untuk memengaruhi perubahan di upstream.

Misalnya, sistem kita membaca data dari layanan pemerintah atau vendor eksternal — mau tidak mau, kita harus “conform”.

Walau kurang ideal, Conformist tetap bisa dikelola dengan baik asalkan dokumentasi kontraknya jelas.

4. Open Host Service dan Published Language

Kadang, satu bounded context melayani banyak konsumen. Daripada menyesuaikan diri dengan masing-masing, lebih efisien kalau dia menyediakan satu antarmuka publik yang stabil.

Pola ini disebut Open Host Service, dan bahasa komunikasinya disebut Published Language.

• Open Host Service → API publik yang terbuka untuk konsumsi banyak sistem.

• Published Language → format data dan istilah yang disepakati (misalnya JSON schema, gRPC proto, atau message contract).

Contoh sederhana:

// Published Language: kontrak publik API
#[derive(serde::Serialize)]
struct OrderDto {
    order_id: u64,
    total: f64,
    status: String,
}

Dengan Published Language, upstream tidak perlu menyesuaikan setiap downstream. Semua berkomunikasi lewat kontrak publik yang stabil, mirip seperti “bahasa diplomatik” antar negara.

5. Separate Ways

Tidak semua bounded context harus saling bicara. Kadang, lebih baik mereka berjalan sendiri-sendiri dengan domain model masing-masing.

Pola Separate Ways digunakan saat:

• Integrasi terlalu rumit dibanding manfaatnya,

• Atau dua sistem hanya berbagi data secara sinkronisasi batch, bukan real-time.

“Sometimes the cost of integration outweighs the benefits.” — Khononov (2022)

Dalam praktiknya, ini justru bisa lebih efisien: tim jadi bebas bereksperimen dan merilis fitur tanpa bergantung satu sama lain.

Menggunakan Context Map

Untuk memvisualisasikan hubungan antar bounded context dan pola komunikasinya, DDD menggunakan Context Map — semacam peta hubungan antar tim atau sistem.

Contohnya:

[Sales Context] ---> [Shipping Context] ---> [Support Context]
       |                   |                       |
    (Customer–Supplier)  (Partnership)         (Separate Ways)

Context Map membantu kita menjawab:

• Siapa upstream, siapa downstream?

• Pola komunikasi apa yang digunakan?

• Siapa yang perlu berkoordinasi untuk perubahan?

Dengan peta ini, arsitektur organisasi menjadi lebih transparan, dan konflik semantik bisa diantisipasi sejak awal.

Ketika Komunikasi Gagal

Kesalahan paling umum dalam integrasi antar context adalah menganggap komunikasi sekadar urusan teknis. Padahal, communication patterns adalah tentang hubungan antar manusia dan tim, bukan hanya antar sistem.

Masalah seperti:

• “API-nya berubah sepihak,”

• “Istilah ‘customer’ di mereka artinya beda,”

• atau “Kita tidak tahu kapan upstream akan rilis versi baru,” semuanya berakar pada komunikasi lintas domain yang buruk.

DDD mengajarkan bahwa solusi teknis harus lahir dari kesepahaman semantik dan kolaborasi antar tim.

Ringkasnya, Komunikasi yang Berarti

Setiap bounded context adalah dunia kecil dengan bahasanya sendiri. Tapi dunia ini tidak bisa hidup sendirian, ia harus berbicara dengan dunia lain.

Communication patterns membantu kita menjaga agar percakapan itu bermakna dan sehat, bukan sekadar pertukaran data.

Arsitektur yang bagus melindungi model dari gangguan teknis, tapi komunikasi yang bagus melindungi model dari kesalahpahaman makna.

Dan pada akhirnya, seperti yang sering diingatkan Khononov: “Domain-Driven Design bukan hanya tentang model dan kode, tapi tentang orang-orang yang berbicara dengan bahasa yang sama.”

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.