https://tokio.rs/tokio/tutorial/setup

Aplikasi bisnis dibangun dengan prinsip domain dan bounded context, sementara sistem data — terutama data lake dan data warehouse — dikelola secara terpusat oleh tim analitik.

to be continued.

Perangkat lunak perlu bereaksi terhadap berbagai kejadian yang muncul di waktu berbeda, dari berbagai sumber, dan kadang tanpa koordinasi langsung.

Inilah konteks di mana Event-Driven Architecture (EDA) menjadi relevan.

Sementara Domain-Driven Design (DDD) fokus pada memahami dan memodelkan domain bisnis,

Event-Driven Architecture fokus pada mengalirkan informasi tentang perubahan domain ke seluruh sistem.

to be continued.

Namun, kenyataannya sering jauh dari harapan: setelah dipecah menjadi banyak service, tim justru kebingungan mengelola dependensi, data tersebar, dan komunikasi antar sistem menjadi mimpi buruk.

Vlad Khononov menyebut fenomena ini dengan sangat tepat:

“Microservices are not the destination — they are the outcome of understanding your domain.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Dengan kata lain, microservices bukan tujuan, melainkan konsekuensi logis dari penerapan DDD yang baik.

Microservices dan Janji Kemerdekaan

Secara konsep, microservice architecture adalah tentang memecah sistem besar menjadi unit-unit kecil yang dapat dikembangkan, dirilis, dan diskalakan secara independen.

Setiap microservice:

• Menangani satu fungsi bisnis tertentu,

• Memiliki data sendiri,

• Dan bisa dikelola oleh satu tim otonom.

Tujuannya terdengar sederhana: independence and scalability. Namun dalam praktiknya, banyak organisasi gagal karena tidak memahami batas domain sebelum membagi service.

“Without understanding domain boundaries, splitting a monolith creates distributed chaos, not distributed systems.” — Khononov, 2022

Dan di situlah peran DDD menjadi sangat penting.

Hubungan DDD dan Microservices

DDD memberi fondasi berpikir yang kuat untuk menentukan batas alami dari setiap microservice, yaitu melalui konsep bounded context.

• DDD Concept: Bounded Context

  • Padanan Microservices: Microservice Boundary

  • Tujuan: Memisahkan logikadan model bisnis secara mandiri

• DDD Concept: Ubiquitous Language

  • Padanan Microservices: Service API Contract

  • Tujuan: Bahasa dan istilah konsisten dalam satu tim

• DDD Concept: Context Map

  • Padanan Microservices: Service Interaction Diagram

  • Tujuan: Hubungan antar service dan pola komunikasinya

• DDD Concept: Communication Pattern

  • Padanan Microservices: API/Event Integration

  • Tujuan: Cara service berkoordinasi tanpa coupling

Jadi, bounded context dalam DDD bukan sekadar konsep abstrak, ia adalah peta alami yang membantu kita menentukan microservice yang sehat.

Bounded Context Sebagai Panduan Desain Microservice

Banyak kegagalan microservice berasal dari salah memotong sistem: dibagi berdasarkan lapisan teknis (UI, backend, database), bukan area bisnis.

Hasilnya: service terlalu kecil, saling bergantung, dan kehilangan makna bisnis.

DDD membantu memotong sistem secara semantik, bukan struktural.

Contoh: Daripada membagi berdasarkan teknologi:

/user-api
/payment-service
/database-service

DDD akan mendorong pembagian berdasarkan domain:

/billing-context
/inventory-context
/customer-context

Setiap context punya logika, data, dan bahasa sendiri, itulah microservice yang benar-benar “domain-driven”.

Integrasi Antar Microservice: Komunikasi Antara Context

Ketika kita punya banyak bounded context (atau microservice), komunikasi di antaranya harus dikelola dengan hati-hati.

DDD memperkenalkan communication patterns yang juga relevan di dunia microservices, seperti:

• Customer–Supplier

• Conformist

• Partnership

• Separate Ways

Dalam konteks arsitektur terdistribusi, pola-pola ini bisa diterjemahkan sebagai:

• Customer–Supplier → satu service tergantung API dari service lain,

• Conformist → mengikuti format upstream tanpa perubahan,

• Partnership → dua tim berkolaborasi erat,

• Separate Ways → berjalan mandiri tanpa integrasi real-time.

Misalnya:

// Contoh komunikasi event-driven antar microservice
#[derive(serde::Serialize, serde::Deserialize)]
struct OrderPlaced {
    order_id: u64,
    total: f64,
}

fn publish_order_placed(order: OrderPlaced) {
    // publish ke message broker (Kafka, NATS, dll)
    println!("Publishing event: {:?}", order);
}

Pendekatan event-driven ini menjaga agar microservice tetap otonom, karena setiap service bereaksi terhadap event, bukan memanggil service lain secara langsung.

Tantangan Microservice di Dunia Nyata

Meski konsepnya indah, arsitektur microservices membawa kompleksitas baru.

Khononov mengingatkan, bahwa:

“Microservices move complexity from code to communication.” — Vlad Khononov, 2022

Mari lihat beberapa jebakan umum yang sering terjadi:

1. Over-segmentation (Service Terlalu Kecil)

Engineer terlalu semangat memecah sistem hingga setiap fungsi menjadi satu service. Akibatnya, integrasi menjadi rumit dan deployment berantakan.

Solusi: Pastikan setiap service punya makna domain utuh (bounded context lengkap), bukan sekadar endpoint CRUD.

2. Shared Database

Beberapa service masih berbagi database yang sama, ini menghapus batas konteks.

Solusi: Setiap service memiliki database sendiri, bahkan jika data yang disimpan mirip. Gunakan event untuk sinkronisasi, bukan query silang.

3. Communication Hell

Service saling memanggil API secara berantai (A → B → C → D). Jika satu mati, semuanya ikut gagal.

Solusi: Gunakan asynchronous messaging (event-driven) untuk mengurangi coupling antar service.

4. Terlalu Banyak Infrastruktur

Microservice memerlukan CI/CD pipeline, monitoring, logging, service mesh, dan sebagainya. Untuk tim kecil, overhead ini bisa lebih mahal daripada manfaatnya.

Solusi: Mulai dari modular monolith, struktur monolit yang sudah terpisah per context. Jika sudah stabil, baru evolusikan ke microservice sejati.

Modular Monolith Sebagai Titik Awal

Khononov menyarankan pendekatan yang realistis:

“Start with a modular monolith. Split it when you must, not when you can.” — Khononov, 2022

Artinya, kamu bisa mulai dengan sistem monolit tunggal, tapi struktur internalnya sudah mengikuti prinsip bounded context.

Contoh struktur folder dalam Rust:

src/
 ├── billing/
 │    ├── domain.rs
 │    ├── service.rs
 │    └── repository.rs
 ├── inventory/
 │    ├── domain.rs
 │    └── service.rs
 └── main.rs

Ketika skala sistem tumbuh, tiap folder domain ini bisa dengan mudah dipecah menjadi microservice independen, karena sejak awal, batas context-nya sudah jelas.

DDD sebagai Landasan Microservice Sehat

Inti dari pesan Khononov sangat sederhana tapi krusial:

“Without DDD, microservices are just distributed monoliths.” — Vlad Khononov (2022)

DDD membantu kita:

1. Menentukan batas yang sehat (bounded contexts),

2. Menjaga otonomi antar tim,

3. Mencegah duplikasi logika bisnis,

4. Menghindari coupling antar service.

Dengan kata lain, DDD adalah kompas yang menunjukkan di mana memotong sistem. Microservices hanyalah hasil fisik dari pemotongan itu.

Ringkasnya, Microservices yang Bermakna

Microservices bukan soal ukuran kecil, tapi soal batas makna yang jelas. Sebuah microservice seharusnya mencerminkan satu domain bisnis yang utuh, bukan sekadar satu tabel di database atau satu endpoint di API gateway.

DDD membantu kita menemukan batas itu, bukan lewat intuisi arsitek, tapi lewat percakapan lintas tim, pemahaman domain, dan bahasa umum yang disepakati.

“Good microservices emerge from good domain models.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Referensi

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

Dan memang benar. Vlad Khononov sendiri menekankan sejak awal bahwa Domain-Driven Design bukanlah metode magis yang menjamin keberhasilan proyek, melainkan sekumpulan pola pikir dan alat bantu untuk memahami serta mengelola kompleksitas.

Dalam bab ini, kita akan melihat bagaimana DDD diterapkan secara pragmatis di dunia nyata, termasuk kesalahpahaman umum, jebakan organisasi, dan strategi agar tetap waras dalam menghadapi kenyataan.

Kenyataan #1: Tidak Semua Sistem Butuh DDD

Salah satu kesalahan paling sering ditemui di dunia profesional adalah menerapkan DDD di semua tempat.

Padahal, tidak semua sistem punya kompleksitas yang layak untuk itu.

DDD diciptakan untuk domain yang:

• Kompleks secara bisnis, bukan hanya teknis.

• Penuh ambiguitas dan aturan yang berubah cepat.

• Memerlukan komunikasi intens antara developer dan domain expert.

Kalau sistem kamu hanya mencatat data CRUD (Create, Read, Update, Delete), maka memakai DDD lengkap akan terasa seperti menggunakan bazooka untuk memecahkan telur.

“DDD is not for every project — it’s for the ones where business complexity rules.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Jadi, if it’s simple, keep it simple. Gunakan pendekatan ringan seperti Transaction Script atau Active Record untuk modul sederhana, dan hanya terapkan DDD penuh pada bagian yang benar-benar strategis.

Kenyataan #2: Organisasi Lebih Sulit dari Kode

DDD sering kali gagal bukan karena engineer tidak paham model, tapi karena organisasi tidak siap untuk cara berpikir kolaboratif.

Di dunia nyata:

• Tim terpisah oleh silo,

• Komunikasi antar departemen buruk,

• “Ahli domain” tidak selalu punya waktu untuk berdiskusi,

• Dan setiap tim punya KPI sendiri-sendiri.

Hasilnya? Setiap orang punya versi modelnya sendiri, dan ubiquitous language yang ideal di buku berubah jadi babel language di kantor.

“The real challenge of DDD is not modeling the software — it’s modeling the organization.” — Khononov, 2022

Strategi realistis: Mulai dari lingkar kecil, satu tim yang mau berkolaborasi penuh. Bangun bounded context pertama di situ, dan buktikan hasilnya. Setelah berhasil, baru tularkan ke tim lain.

Kenyataan #3: Bounded Context Itu Tidak Harus Rapi

Di teori, bounded context terlihat jelas: setiap domain punya batas logis, bahasa sendiri, dan modelnya tidak tumpang-tindih.

Tapi di dunia nyata, batas itu sering kabur:

• Ada konteks yang saling tumpang tindih,

• Ada istilah yang “nyasar” karena kebutuhan API,

• Kadang satu tim harus mengurusi dua domain karena alasan praktis.

Dan itu tidak apa-apa.

DDD bukan tentang kesempurnaan arsitektur, tapi tentang kesadaran terhadap batasan. Selama tim sadar di mana batas tanggung jawabnya, DDD tetap hidup.

“It’s okay if your boundaries are blurry — as long as you know they’re blurry.” — Khononov, 2022

Contohnya, dua tim mungkin sama-sama menggunakan istilah Order. Tapi yang penting adalah:

• Mereka tahu makna “Order” di masing-masing context,

• Dan mereka tidak saling memaksakan model satu sama lain.

Kenyataan #4: Model Akan Selalu Berubah

Sering kali, tim DDD pemula ingin membuat domain model final sebelum mulai coding. Padahal, seperti dibahas di Bab 11, model domain itu hasil belajar, bukan hasil perencanaan.

Model yang baik bukan yang paling stabil, tapi yang paling mudah beradaptasi.

Praktik nyata: Gunakan pendekatan event-driven untuk memantau perubahan domain. Setiap kali muncul event baru yang tidak masuk akal, itu tanda modelmu butuh revisi.

Misalnya:

// Model awal
enum OrderStatus {
    Pending,
    Paid,
}

// Setelah bisnis menambah fitur refund
enum OrderStatus {
    Pending,
    Paid,
    Refunded,
}

Model berkembang bukan karena salah di awal, tapi karena bisnis berubah dan pengetahuan bertambah.

Kenyataan #5: Kompromi Itu Wajar

Setiap proyek di dunia nyata berhadapan dengan tiga tekanan utama:

1. Waktu: deadline yang ketat,

2. Sumber daya: tim kecil, beban besar,

3. Teknologi warisan (legacy): keputusan lama yang sulit diubah.

Dan di tengah tekanan itu, idealisme DDD kadang harus dikompromikan.

“A pragmatic architect knows when to bend the rules.” — Khononov, 2022

Kompromi tidak berarti menyerah. Yang penting adalah tahu kapan dan kenapa melanggar prinsip.

Contoh kompromi sehat:

• Sementara gunakan model anemik (tanpa logika bisnis di entitas), lalu perlahan refactor ketika domain makin jelas.

• Tulis event secara manual dulu tanpa bus, lalu evolusikan jadi event-driven architecture saat skalanya cukup besar.

• Gunakan shared database sementara untuk sinkronisasi antar context, tapi tandai sebagai temporary coupling.

Kunci keberhasilan DDD di dunia nyata adalah transparansi dalam kompromi.

Kenyataan #6: DDD Adalah Perjalanan, Bukan Tujuan

Banyak tim berpikir bahwa “menerapkan DDD” adalah milestone yang bisa dicapai. Padahal, DDD itu bukan proyek — ia cara berpikir yang berkelanjutan.

DDD yang sehat terlihat bukan dari diagram yang indah, tapi dari komunikasi yang lancar antar tim, pemahaman yang jelas tentang domain, dan model yang tumbuh bersama bisnis.

“The success of DDD is not measured in aggregates, but in shared understanding.” — Vlad Khononov (2022)

Ketika orang bisnis, developer, dan QA bisa berbicara tanpa translator, itulah saat DDD benar-benar hidup, bahkan tanpa disebut DDD.

Kenyataan #7: Legacy Systems Bisa Diperbaiki Bertahap

Banyak perusahaan tidak memulai dari nol. Mereka punya sistem lama, penuh logika bercampur, dan database yang menua.

Kabar baiknya: DDD bisa diterapkan secara bertahap.

Mulailah dari memetakan domain dan event dengan EventStorming (Bab 12). Temukan bounded context tersembunyi di dalam monolit, dan pisahkan secara evolusioner.

Contohnya, dari monolit besar, ekstrak satu domain kecil seperti Invoice Management menjadi microservice mandiri dengan domain model sendiri.

Dengan cara itu, DDD menjadi strategi perbaikan berkelanjutan, bukan proyek overhaul besar.

Heuristik untuk Bertahan di Dunia Nyata

Khononov menutup buku ini dengan beberapa heuristik penting bagi praktisi DDD:

• Heuristik: Mulai dari percakapan, bukan kode.

  • Penjelasan: DDD lahir dari dialog dengan domain expert.

• Heuristik: Desain secukupnya.

  • Penjelasan: Tidak semua bagian butuh arsitektur kompleks.

• Refactor berdasarkan pembelajaran.

  • Penjelasan: Evolusi model harus mengikuti realitas bisnis.

• Gunakan bahasa bisnis di kode.

  • Penjelasan: Nama-nama class, function, dan event harus masuk akal bagi non-engineer.

• Toleransi terhadap kekacauan.

  • Penjelasan: Di awal, model pasti berantakan — dan itu normal.

• Rayakan perbaikan kecil.

  • Penjelasan: Setiap domain yang jadi lebih mudah dipahami adalah kemenangan.

Ringkasnya, DDD yang Sejati Adalah DDD yang Hidup

Pada akhirnya, DDD bukan tentang pola, agregat, atau bounded context yang sempurna. DDD adalah tentang membawa makna bisnis ke dalam perangkat lunak dengan cara yang bisa berkembang bersama waktu.

Di dunia nyata, DDD yang berhasil bukan yang 100% sesuai buku, tapi yang 100% dipahami oleh orang-orang yang membangunnya.

“Perfect DDD doesn’t exist — but meaningful DDD does.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Referensi

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

melainkan menyatukan pemahaman antara orang-orang yang berbicara bahasa berbeda:

engineer, product manager, domain expert, dan stakeholder bisnis.

Setiap orang membawa perspektifnya sendiri:

• Engineer berpikir dalam entitas dan API,

• Product manager berpikir dalam fitur,

• Domain expert berpikir dalam proses dan peraturan bisnis.

Dan sering kali, perbedaan bahasa ini membuat diskusi berputar tanpa hasil.

Nah, EventStorming hadir untuk menjembatani semua itu.
Ini bukan teknik coding, tapi teknik berpikir dan berkolaborasi visual agar tim memahami domain dengan cara yang sama.

“EventStorming is a workshop-based method to explore complex domains by focusing on domain events.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Apa Itu EventStorming?

Secara sederhana, EventStorming adalah cara memetakan alur bisnis dengan menulis peristiwa-peristiwa (event) yang terjadi di domain, biasanya di atas dinding atau papan besar dengan sticky notes berwarna.

Kata “Storming” di sini menggambarkan proses eksplorasi yang intens dan cepat, bukan diskusi formal yang kaku.
Tujuannya bukan langsung “mendesain arsitektur,” tapi mendapatkan pemahaman utuh tentang bagaimana domain bekerja dari perspektif semua pihak.

Kata kuncinya:
Semua orang bisa berkontribusi, semua ide valid, dan peristiwa (event) adalah bahasa pemersatu.

Kenapa EventStorming Penting dalam DDD

DDD berfokus pada pemahaman domain.
Tapi sering kali, pengetahuan domain tidak tertulis dengan rapi,
ia tersebar di kepala orang-orang, dokumen lama, atau asumsi tim.

EventStorming membantu:

1. Menyatukan semua stakeholder di satu ruangan (atau papan digital).

2. Menyingkap logika bisnis tersembunyi lewat diskusi natural.

3. Membentuk bahasa umum (ubiquitous language) dari kejadian nyata di domain.

4. Menemukan batas-batas alami (bounded contexts) berdasarkan pola peristiwa.

Dengan kata lain, EventStorming adalah cara tercepat untuk “menemukan domain model” sebelum menulis satu baris kode pun.

Prinsip Utama: Berpikir dalam “Event”

Daripada bertanya “entitas apa yang kita butuhkan?”, facilitator EventStorming akan memulai dengan pertanyaan sederhana: “Apa saja yang terjadi di domain ini?”

Setiap jawaban ditulis dalam format Domain Event, sesuatu yang terjadi di masa lalu dan relevan bagi bisnis.

Contohnya:

• OrderPlaced

• PaymentReceived

• ShipmentSent

• CustomerRegistered

Setiap event ditempel di dinding dari kiri ke kanan, menggambarkan urutan waktu.

Dari situ, perlahan terbentuk narasi: bagaimana proses bisnis berjalan, siapa yang terlibat, dan di mana kompleksitas muncul.

Warna dan Artefak Utama

EventStorming biasanya menggunakan sticky note dengan warna berbeda, yang masing-masing mewakili artefak penting dalam domain.

• Oranye: Artefak Domain Event

  • Artinya: Sesuatu yang terjadi di masa lalu

• Biru: Artefak Command

  • Artinya: Tindakan yang menyebabkan Event

• Kuning: Artefak External System / Policy

  • Artinya: Sistem atau aturan luar yang memicu tindakan

• Merah muda: Artefak Actor / User

  • Artinya: Siapa yang menjalankan command

• Hijau: Artefak View / Read Model

  • Artinya: Informasi yang dilihat pengguna

• Ungu: Artefak Aggregate / Entity

  • Artinya: Unit logika bisnis yang menangani command

Tidak semua workshop butuh semua warna. Fokusnya bukan estetika, tapi pemahaman bersama tentang hubungan sebab-akibat di domain.

Fase-Fase EventStorming

Menurut Khononov (2022), proses EventStorming umumnya terdiri dari beberapa tahap yang semakin mendalam.

1. Big Picture EventStorming

Tujuannya: menemukan alur bisnis secara keseluruhan.

Peserta dari berbagai fungsi (bisnis, teknis, operasional) diminta menuliskan semua event penting dalam proses.
Hasilnya sering kali berantakan — dan itu bagus! Karena di sanalah percakapan penting muncul.

Contoh:
Ketika seseorang menulis PaymentFailed, peserta lain mungkin bertanya,
“Lho, itu terjadi sebelum atau sesudah OrderCancelled?”
Diskusi seperti itu mengungkap aturan bisnis implisit yang selama ini tidak pernah terdokumentasi.

2. Process-Level EventStorming

Setelah gambaran besar terbentuk, tim bisa memperdalam satu proses spesifik, misalnya Order Fulfillment.
Di tahap ini, kita mulai melihat command, actor, dan aggregate yang terlibat.

Misalnya:

• Command: PlaceOrder

• Aggregate: Order

• Event: OrderPlaced

• Actor: Customer

Dan mungkin muncul insight seperti: “Kalau stok tidak cukup, event OrderRejected bisa muncul.”

Dari sini, kita mulai melihat pola bounded context dan logika bisnis yang nyata.

3. Design-Level EventStorming

Tahap ini paling teknis, dilakukan biasanya oleh engineer dan arsitek sistem.
Di sini, event dan command diterjemahkan ke dalam komponen desain seperti:

• Aggregate (logika domain utama)

• Saga / Process Manager (mengatur alur lintas aggregate)

• Read Model / Projection (untuk query data)

• External System Integration (pihak ketiga)

Contoh dalam Rust (sketsa sederhana):

struct Order {
    id: u64,
    status: OrderStatus,
}

impl Order {
    fn place(&mut self) -> OrderPlaced {
        self.status = OrderStatus::Placed;
        OrderPlaced { order_id: self.id }
    }
}

struct OrderPlaced {
    order_id: u64,
}

Dari event yang awalnya hanya sticky note oranye, kini kita bisa melihat kode yang berbicara dengan bahasa bisnis yang sama.

Temuan yang Sering Muncul dari EventStorming

EventStorming bukan hanya latihan pemetaan, ini adalah alat diagnosis organisasi.

Beberapa temuan umum:

• Ambiguitas istilah: orang berbeda menyebut hal yang sama dengan istilah berbeda.

• Kekosongan tanggung jawab: ada event tanpa command yang jelas.

• Masalah komunikasi antar tim: event muncul di satu context tapi dikonsumsi di context lain tanpa koordinasi.

• Aturan bisnis tersembunyi: “oh ternyata itu otomatis dibatalkan kalau lewat 24 jam!”

Setiap temuan seperti ini adalah pengetahuan domain baru, dan itulah nilai utama EventStorming.

Nilai Praktis bagi Engineer

Bagi engineer, EventStorming terasa seperti cheat code untuk memahami domain baru.

Alih-alih membaca dokumen setebal 50 halaman atau menebak-nebak lewat backlog Jira, kita bisa melihat alur bisnis hidup di depan mata.

Kita tahu:

• Event apa yang penting,

• Siapa yang memicunya,

• Kondisi apa yang menyebabkannya gagal,

• Dan bagaimana satu bounded context memengaruhi yang lain.

Setelah workshop, kode yang kita tulis jadi jauh lebih dekat dengan cara bisnis berpikir.

EventStorming dan Bounded Context

Salah satu hasil alami dari EventStorming adalah munculnya pola pemisahan alami antar bagian domain.

Ketika papan mulai “penuh”, kita bisa mulai melihat klaster event yang saling erat, itulah kandidat bounded context.

“Bounded contexts don’t come from architects — they emerge from understanding.” — Vlad Khononov, 2022

Bounded context yang ditemukan dengan cara ini jauh lebih realistis, karena tumbuh dari percakapan lintas tim, bukan dari diagram PowerPoint.

Kapan Menggunakan EventStorming

Gunakan EventStorming ketika:

• Tim baru akan memulai proyek besar,

• Domain masih kabur atau penuh asumsi,

• Ada ketegangan antar tim atau model yang tidak selaras,

• Atau ketika organisasi ingin membangun ubiquitous language.

Sebaliknya, untuk sistem kecil atau domain yang sudah stabil, EventStorming mungkin berlebihan, cukup gunakan diagram alur sederhana.

Tips Memfasilitasi EventStorming

1. Mulai dari event, bukan dari entitas.
   Jangan tanya “objek apa yang kita punya?”, tapi “apa yang terjadi?”

2. Dorong partisipasi semua pihak.
   Tidak ada jawaban salah. Justru ketidaksepakatan itu bahan diskusi.

3. Gunakan papan besar dan sticky notes.
   Visualisasi itu penting, otak manusia lebih cepat memahami pola.

4. Beri ruang untuk chaos.
   Di awal pasti berantakan, tapi dari kekacauan itu muncul struktur.

5. Akhiri dengan insight, bukan diagram sempurna.
   Tujuan utama: pemahaman bersama, bukan artefak yang rapi.

Ringkasnya, ini adalah Percakapan yang Mengubah Cara Berpikir

EventStorming bukan alat teknis, ia alat manusiawi.
Ia mengubah cara tim memahami domain dari debat tentang solusi menjadi percakapan tentang kejadian nyata.

Setelah workshop, semua orang, baik engineer, PM, maupun ahli bisnis, akan mulai berbicara dengan bahasa yang sama. Dan itu, dalam semangat DDD, adalah kemenangan terbesar.

“Software design is a communication game. EventStorming makes the rules visible.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Referensi

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

Di artikel-artikel sebelumnya, kita belajar bahwa domain model itu hidup. Ia berkembang seiring perubahan bisnis dan pemahaman tim.

Tapi bukan hanya model domain yang perlu berevolusi. Keputusan desain dan arsitektur pun harus mengikuti — karena yang kita tahu hari ini belum tentu benar besok.

“Good design decisions are not permanent. They are just good for now.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Inilah inti dari bab ini: desain yang baik adalah desain yang bisa tumbuh bersama waktu dan pengetahuan.

Mengapa Desain Harus Berevolusi

Kita sering berpikir desain itu seperti kontrak: sekali diputuskan, harus dijaga mati-matian. Padahal, dunia bisnis bergerak cepat. Aturan baru muncul, model berubah, skala sistem bertambah, bahkan teknologi pun bergeser.

Keputusan yang dulu tepat bisa jadi tidak relevan hari ini. Maka, desain yang sehat bukan yang “tidak berubah”, tapi yang mudah berubah tanpa menyakitkan.

Contoh sederhana:

Awalnya sistem pembayaran hanya mendukung cash dan transfer bank, jadi cukup enum sederhana:

enum PaymentMethod {
    Cash,
    BankTransfer,
}

Tiga bulan kemudian, muncul kebutuhan baru: QRIS, kartu kredit, e-wallet, bahkan voucher internal.

Kalau arsitektur kita kaku, perubahan kecil seperti ini bisa menyentuh banyak tempat sekaligus — error di mana-mana. Tapi kalau modelnya fleksibel, kita cukup menambah varian baru tanpa mengubah bagian lain:

enum PaymentMethod {
    Cash,
    BankTransfer,
    CreditCard(String),
    EWallet(String),
    Voucher(String),
}

Desain yang bisa berevolusi seperti ini menunjukkan bahwa arsitektur kita adaptif terhadap perubahan pengetahuan.

Desain Itu Proses Pembelajaran

Khononov menjelaskan bahwa desain bukan hasil akhir dari perencanaan panjang, melainkan hasil iterasi dari proses belajar.

Setiap diskusi dengan domain expert, setiap bug, dan setiap perilaku pengguna membawa insight baru tentang domain. Dengan setiap wawasan baru itu, kita perlu memperbarui model, dan kadang mengubah keputusan desain sebelumnya.

“Design is learning, and learning means change.” — Vlad Khononov, 2022

Desain DDD bukan soal menemukan struktur paling indah, tapi soal menemukan struktur yang paling menggambarkan kenyataan saat ini.

Perbedaan Antara Desain yang Kaku dan Desain yang Berevolusi

Aspek Desain Kaku

• Fokus: Kepastian

• Tujuan: Menghindari perubahan

• Strategi: Rencana besar di awal

• Efek samping: Cepat usang

• Pola pikir: “Sudah benar dari awal”

Aspek Desain Berevolusi

• Fokus: Adaptasi

• Tujuan: Menyambut perubahan

• Strategi: Iterasi kecil dan terus-menerus

• Efek samping: Selalu relevan

• Pola pikir: “Kita belajar setiap hari”

Desain kaku lahir dari ketakutan akan salah. Desain yang berevolusi lahir dari rasa ingin tahu dan keberanian untuk mengoreksi diri.

Teknik: Menunda Keputusan Secara Sengaja

Salah satu prinsip desain penting yang diperkenalkan dalam buku ini adalah delaying decisions — menunda keputusan desain sampai kita punya cukup informasi.

Istilah ini sering disebut Last Responsible Moment:

“Ambil keputusan selambat mungkin, tapi tidak sampai terlambat.”

Artinya, jangan buat keputusan desain besar saat masih banyak ketidakpastian. Ambil keputusan yang paling ringan dulu, yang bisa dengan mudah diubah nanti.

Contoh: Daripada langsung memilih pattern besar seperti CQRS + Event Sourcing, mulailah dengan Layered Architecture. Begitu sistem makin kompleks dan kebutuhan audit muncul, kamu bisa evolusikan jadi CQRS.

Atau, daripada menentukan teknologi database di awal, abstraksikan akses datanya lewat Repository Interface. Kalau nanti migrasi dari SQLite ke PostgreSQL, domain model tetap aman.

trait OrderRepository {
    fn save(&self, order: &Order);
    fn find_by_id(&self, id: u64) -> Option<Order>;
}

Keputusan kecil ini menjaga fleksibilitas tanpa mengorbankan arah.

Prinsip: Keputusan Harus Proporsional dengan Pengetahuan

Khononov menyebut bahwa setiap keputusan desain adalah pertukaran antara pengetahuan dan risiko.

• Semakin sedikit pengetahuan yang kita punya, semakin besar risiko salah mengambil keputusan.

• Maka, keputusan harus sepadan dengan tingkat pemahaman kita saat itu.

Jangan terlalu dini membuat keputusan besar atas asumsi mentah. Sebaliknya, jangan juga terlalu lama menunda hingga tim kehilangan arah.

Prinsip ini mendorong pola pikir evolutionary architecture, arsitektur yang tidak selesai di atas kertas, melainkan terus dibentuk dari pengalaman nyata.

Tanda-tanda Kamu Butuh Mengubah Desain

1. Banyak “if” di mana-mana. Itu tanda model sudah tidak mencerminkan domain lagi.

2. Aturan bisnis sulit dijelaskan lewat kode. Mungkin modelmu sudah terlalu teknis.

3. Istilah di kode dan di meeting mulai berbeda. Bahasa umum (ubiquitous language) sudah melenceng.

4. Perubahan kecil memengaruhi banyak bagian. Tanda struktur sistem sudah terlalu rapuh.

5. Tim mulai takut refactor. Ini gejala klasik desain yang membatu.

Kalau ini mulai terasa, jangan panik. Itu bukan kegagalan, itu sinyal bahwa kamu sudah belajar sesuatu yang baru, dan saatnya model ikut berubah.

Pendekatan: Continuous Refinement

Evolusi desain tidak butuh revolusi besar setiap enam bulan. Cukup lakukan refinement kecil secara terus-menerus.

Langkah sederhananya:

1. Identifikasi pain point. Misalnya entitas tertentu jadi terlalu besar.

2. Diskusikan dengan domain expert. Apakah ada istilah atau proses baru?

3. Perbaiki model. Pecah aggregate, ubah value object, atau tambahkan event.

4. Uji asumsi. Pastikan perubahan benar-benar memudahkan pemahaman bisnis.

5. Rilis kecil. Jangan tunda sampai “semua siap”.

Refinement yang berkelanjutan jauh lebih sehat daripada refactor masif yang menakutkan.

Mengelola Tekanan dan Trade-off

Kadang manajemen ingin keputusan cepat: “Pilih framework sekarang!” Atau: “Kita harus finalkan model minggu ini!”

Dalam konteks DDD, tugas engineer bukan hanya membuat kode, tapi juga melindungi proses belajar. Artinya, jangan biarkan tekanan waktu membunuh kesempatan untuk memahami domain dengan benar.

Kita boleh mengambil keputusan pragmatis sementara — asal sadar bahwa itu keputusan sementara, dan siap diperbaiki nanti.

“Every temporary decision is a debt — pay it back when knowledge grows.” — Vlad Khononov, 2022

Kode Sebagai Dokumentasi Evolusi

Model domain yang baik seharusnya menjadi dokumentasi hidup tentang cara bisnis bekerja saat ini. Jangan takut kalau modelmu berbeda dari enam bulan lalu — itu tanda kamu belajar.

Gunakan git commit, test case, dan domain event sebagai jejak sejarah evolusi keputusan desain.

Contoh:

// Sebelum
enum DeliveryStatus {
    Pending,
    Delivered,
}

// Setelah memahami proses retur
enum DeliveryStatus {
    Pending,
    Delivered,
    Returned(String), // alasan pengembalian
}

Setiap perubahan semacam ini adalah bukti bahwa sistemmu menyesuaikan diri dengan realitas bisnis, bukan sebaliknya.

Ringkasan mengenai Desain yang Tumbuh Bersama Pengetahuan

DDD bukan hanya tentang membuat model domain, tapi tentang membangun sistem yang terus belajar.

Desain yang baik tidak kaku. Ia tumbuh bersama tim, bersama bisnis, dan bersama waktu.

Prinsip utamanya sederhana:

• Jangan kunci keputusan sebelum waktunya.

• Jangan takut mengubah arah saat pengetahuan bertambah.

• Dan yang paling penting: pastikan perubahan desain selalu mengikuti makna bisnis, bukan sekadar selera teknis.

“The best design is the one that fits the current understanding of the domain — and is ready to change when that understanding grows.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Referensi

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

Jika di pembahasan sebelumnya kita belajar tentang semua elemen keren di DDD — dari bounded context, aggregate, sampai communication patterns, mungkin kini muncul pertanyaan praktis:

“Kapan sih kita benar-benar perlu pakai DDD? Apakah semua bagian sistem harus pakai domain model penuh?”

Jawabannya singkat tapi penting: tidak selalu. Dan di sinilah kita mulai masuk ke inti bab ini: design heuristics — kumpulan prinsip berpikir agar kita tahu seberapa dalam menerapkan DDD, dan kapan harus berhenti sebelum berlebihan.

Heuristik: Bukan Aturan, Tapi Kompas

Kata heuristic berarti “petunjuk praktis untuk membuat keputusan yang baik dalam kondisi tidak pasti.” Dalam konteks DDD, heuristik membantu kita memilih pendekatan desain yang seimbang antara nilai bisnis dan biaya implementasi.

DDD bukan dogma. Ia bukan tentang “semua harus punya domain model lengkap.” Ia adalah cara berpikir agar sistem kita mencerminkan realitas bisnis secukupnya — tidak kurang, tapi juga tidak berlebihan.

“Heuristics are not rules — they are good advice for most situations.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Prinsip Dasar 1: Gunakan Kompleksitas dengan Bijak

DDD diciptakan untuk domain yang kompleks secara bisnis, bukan sekadar teknis. Kalau sistem kamu hanya memindahkan data antar tabel tanpa aturan khusus, maka DDD penuh justru akan memperlambat tim.

Bayangkan sistem sederhana seperti user management, login, atau report generator. Fungsi-fungsi itu bisa selesai dengan cepat pakai pola Transaction Script atau Active Record.

Tapi ketika mulai muncul hal-hal seperti:

• “kalau pengguna premium, logika perhitungan komisinya berbeda,”

• “status langganan berubah otomatis tergantung perilaku,”

• “ada peraturan bisnis yang saling bertabrakan,”

maka itu tanda domain mulai kompleks. Dan di situlah Domain Model menjadi alat yang tepat.

Heuristik #1: Semakin kompleks logika bisnis, semakin layak DDD digunakan.

Prinsip Dasar 2: Model Harus Menghasilkan Nilai Bisnis

Kadang engineer terjebak membangun model yang indah tapi tidak berdampak. DDD tidak mengejar keindahan teknis, tapi kejelasan makna bisnis.

Sebelum membuat entitas, aggregate, atau event, selalu tanyakan:

“Apakah model ini membantu tim memahami atau memecahkan masalah bisnis?”

Kalau jawabannya tidak, mungkin kamu sedang membuat arsitektur demi arsitektur.

Contoh sederhana:

Katakan kita sedang membangun sistem pembelian tiket.

Model yang bermanfaat:

struct Ticket {
    id: u64,
    status: TicketStatus,
}

enum TicketStatus {
    Reserved,
    Paid,
    Cancelled,
}

Model yang “terlalu DDD tapi tidak berguna”:

struct TicketAggregate {
    id: u64,
    ticket_entity: TicketEntity,
    ticket_state: TicketState,
    ticket_repository: Arc<dyn Repository>,
}

Yang satu berbicara tentang tiket dan statusnya, yang lain berbicara tentang framework dan istilah arsitektur. Model yang baik selalu dekat dengan bahasa domain, bukan dengan jargon teknis.

Heuristik #2: Model yang baik berbicara dalam bahasa bisnis, bukan bahasa framework.

Prinsip Dasar 3: Pisahkan Domain yang Penting dari yang Biasa

Tidak semua bagian sistem punya nilai strategis yang sama. Beberapa bagian adalah core domain — di sanalah keunggulan kompetitif bisnis berada. Yang lain hanyalah supporting atau bahkan generic subdomain.

Gunakan tenaga DDD di tempat yang paling berdampak.

Jenis Domain Fokus Pendekatan Core Domain Inovasi, keunggulan kompetitif Domain Model penuh (DDD taktis lengkap) Supporting Domain Mendukung operasi Pola sederhana seperti Active Record Generic Domain Umum untuk semua bisnis Gunakan library atau SaaS

Contoh nyata:

• Core Domain: algoritme rekomendasi di e-commerce.

• Supporting Domain: sistem pembayaran internal.

• Generic Domain: login, autentikasi, logging.

Heuristik #3: Investasikan DDD di tempat yang memberi nilai strategis terbesar.

Prinsip Dasar 4: Jangan Jadikan DDD Sebagai Target, Tapi Sebagai Alat

Engineer yang baru mengenal DDD sering terlalu semangat: semua hal dibuat Aggregate, semua entitas punya Repository, semua event dicatat.

Padahal DDD bukan checklist, melainkan toolbox. Gunakan hanya alat yang relevan untuk masalah di depan mata.

Heuristik #4: DDD bukan tujuan akhir, melainkan sarana untuk memahami dan menyelesaikan kompleksitas.

Ciri bahwa kamu terlalu jauh: model makin abstrak, tapi semua orang di tim justru makin bingung. Ciri bahwa kamu tepat: model membantu tim berdebat tentang bisnis, bukan tentang kode.

Prinsip Dasar 5: Evolve, Don’t Freeze

Model domain bukan kontrak permanen. Ia seharusnya tumbuh bersama pemahaman bisnis.

Ketika aturan bisnis berubah, biarkan model ikut berevolusi. Jangan terjebak pada rasa takut “merusak arsitektur yang sudah rapi.”

Heuristik #5: Model yang hidup lebih berguna daripada model yang sempurna.

Misalnya, awalnya kamu hanya punya dua status pembayaran: Pending dan Paid. Lalu muncul kebutuhan “Refunded”. Tambahkan saja, meskipun awalnya belum semua proses mendukung.

enum PaymentStatus {
    Pending,
    Paid,
    Refunded,
}

Model berkembang, pengetahuan bertambah — persis seperti bisnisnya.

Prinsip Dasar 6: Biarkan Bounded Context Mengatur Diri Sendiri

Ketika sistem tumbuh besar, mudah tergoda membuat “model universal” yang bisa dipakai semua tim. Padahal itu berbahaya.

Model yang terlalu umum akan kehilangan makna di setiap konteks. Lebih baik setiap bounded context punya modelnya sendiri — walau istilahnya sama tapi maknanya berbeda.

Contoh nyata:

• Di Sales Context, “Customer” berarti orang yang membeli produk.

• Di Support Context, “Customer” berarti orang yang sedang punya tiket bantuan aktif.

Keduanya sah. Yang penting, mereka tidak saling memaksakan makna.

Heuristik #6: Hargai otonomi bounded context — lebih baik model ganda yang jelas daripada model tunggal yang membingungkan.

Prinsip Dasar 7: Arsitektur Ada untuk Melayani Domain

Jangan biarkan framework atau pola arsitektur membatasi desain domain. Ingat bahwa model domain adalah pusat dari sistem, bukan lapisan di bawah framework.

Kalau framework ORM memaksa semua entitas harus punya id integer, padahal di domain kamu lebih masuk akal pakai code sebagai identitas, maka ubahlah framework, bukan domainnya.

struct Product {
    code: String, // Bukan ID auto-increment
    name: String,
}

Heuristik #7: Framework boleh diganti, domain tidak.

Prinsip Dasar 8: Ubiquitous Language Adalah Tes Terbaik

Kalau kamu ingin tahu seberapa sehat model domainmu, lihat bagaimana tim berbicara tentang bisnisnya.

Kalau engineer, PM, dan ahli domain bisa bicara tentang “Order”, “Refund”, dan “Shipment” tanpa kebingungan — artinya modelmu sudah bekerja. Kalau tiap meeting diwarnai “maksud kamu order yang di database atau order yang di API?”, artinya modelmu butuh perbaikan.

Heuristik #8: Jika bahasa di kode dan di percakapan bisnis sama, kamu sedang menerapkan DDD dengan benar.

Ringkasnya, Pragmatism is the Real DDD

DDD bukan sekadar teori elegan untuk sistem besar. Ia adalah cara berpikir untuk memastikan bahwa software yang kita bangun selalu berbicara tentang bisnis, bukan sekadar data.

Namun, setiap engineer yang matang tahu:

• Tidak semua sistem butuh domain model penuh,

• Tidak semua konteks perlu aggregate,

• Dan tidak semua tim siap hidup dengan kompleksitas DDD sejak hari pertama.

Gunakan heuristics sebagai kompas, bukan peta mutlak. Tugas kita bukan membuat DDD sempurna, tapi membuat sistem yang bermakna, terpelihara, dan berumur panjang.

“The goal of DDD is not to apply all its patterns, but to use the right ones, in the right context, for the right reasons.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Referensi

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

“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.

Inilah peran architecture patterns, arsitektur perangkat lunak yang membantu memisahkan logika bisnis dari hal-hal teknis, agar domain model tidak tenggelam di tengah “kebisingan” infrastruktur.

Arsitektur Itu Bukan Soal Layer Saja

Kebanyakan engineer mendengar kata “arsitektur” lalu langsung berpikir tentang layered architecture, lapisan presentasi, logika bisnis, dan data. Padahal, arsitektur dalam konteks DDD bukan cuma soal membagi layer, tapi menentukan bagaimana model domain berinteraksi dengan bagian lain dari sistem.

Arsitektur adalah cara menjaga agar domain model tetap berdaulat, tidak dikendalikan oleh framework, database, atau API eksternal.

Dalam DDD, domain model adalah “raja”, dan arsitektur adalah istana yang melindunginya.

Mengapa Butuh Pola Arsitektur?

Tanpa pola arsitektur yang jelas, kode domain akan cepat “tercemar” oleh hal-hal teknis. Awalnya mungkin cuma satu query SQL di dalam entitas, lalu satu logika HTTP handler di service. Lama-lama model domain kehilangan fokus, menjadi campuran antara logika bisnis, UI, dan infrastruktur.

Inilah yang menyebabkan Big Ball of Mud, sistem yang sulit dipahami karena semua bagian saling menempel tanpa batas yang jelas.

Pola arsitektur membantu kita menetapkan batas tanggung jawab (separation of concerns) antara:

• Domain logic (apa yang bisnis lakukan),

• Application logic (kapan bisnis dijalankan),

• dan Infrastructure logic (bagaimana bisnis dijalankan di dunia nyata).

Beberapa Pola Arsitektur Umum

Buku Khononov (2022) membahas beberapa pola arsitektur yang sering digunakan dalam implementasi DDD: Layered Architecture, Ports and Adapters (Hexagonal Architecture), dan CQRS. Mari kita bahas satu per satu dengan contoh sederhana.

1. Layered Architecture, Struktur Paling Umum

Arsitektur berlapis ini mungkin paling dikenal. Biasanya terdiri dari tiga atau empat lapisan:

+------------------------+
|   Presentation Layer   |
+------------------------+
|   Application Layer    |
+------------------------+
|   Domain Layer         |
+------------------------+
|   Infrastructure Layer |
+------------------------+

• Presentation Layer Menangani interaksi dengan pengguna atau sistem lain (API, UI, CLI).

• Application Layer Mengatur flow atau urutan operasi — kapan bisnis dieksekusi.

• Domain Layer Tempat Entity, Value Object, dan Domain Service berada.

• Infrastructure Layer Berisi detail teknis seperti database, file system, atau network.

Contoh sederhana (Rust):

// Domain Layer
struct Order {
    id: u64,
    total: f64,
}

impl Order {
    fn confirm(&mut self) {
        println!("Order {} dikonfirmasi", self.id);
    }
}

// Application Layer
fn confirm_order(order_repo: &mut impl OrderRepository, id: u64) {
    if let Some(mut order) = order_repo.find_by_id(id) {
        order.confirm();
        order_repo.save(order);
    }
}

// Infrastructure Layer
trait OrderRepository {
    fn find_by_id(&self, id: u64) -> Option<Order>;
    fn save(&mut self, order: Order);
}

Layered architecture mudah dipahami, cocok untuk banyak aplikasi. Namun, jika tidak dijaga dengan disiplin, lapisan bisa bocor, logika bisnis sering naik ke Application Layer atau turun ke Infrastructure Layer.

2. Ports and Adapters (Hexagonal Architecture)

Kadang disebut juga Hexagonal Architecture, pola ini dikembangkan oleh Alistair Cockburn. Tujuannya: memisahkan domain dari dunia luar lewat port (antarmuka) dan adapter (implementasi teknis).

Bayangkan domain sebagai inti heksagon, dan setiap sisi dihubungkan oleh “port” yang bisa dipasang atau dilepas sesuai kebutuhan: API, database, atau event queue.

           +-----------------------+
           |    Presentation API   |
           +-----------+-----------+
                       |
         +-------------+-------------+
         |       Domain Core         |
         | (Entities, Services, etc) |
         +-------------+-------------+
                       |
           +-----------+-----------+
           | Infrastructure / DB   |
           +-----------------------+

Kuncinya: Domain tidak tahu siapa yang memanggilnya, dan tidak peduli siapa yang menyimpan datanya.

Contoh sederhana (Rust):

// Port (interface)
trait PaymentGateway {
    fn pay(&self, amount: f64) -> bool;
}

// Domain core
struct PaymentService<'a> {
    gateway: &'a dyn PaymentGateway,
}

impl<'a> PaymentService<'a> {
    fn process(&self, amount: f64) {
        if self.gateway.pay(amount) {
            println!("Pembayaran berhasil!");
        } else {
            println!("Pembayaran gagal.");
        }
    }
}

// Adapter (implementasi)
struct FakeGateway;

impl PaymentGateway for FakeGateway {
    fn pay(&self, _amount: f64) -> bool {
        true
    }
}

Dengan pola ini, kita bisa mengganti implementasi PaymentGateway tanpa menyentuh kode domain. Mau pakai Midtrans, Stripe, atau simulator lokal, tinggal ganti adapter-nya.

3. CQRS (Command Query Responsibility Segregation)

CQRS memisahkan dua jenis operasi utama sistem:

• Command → mengubah data (buat, ubah, hapus).

• Query → membaca data.

Tujuannya agar keduanya bisa berevolusi dengan kebutuhan berbeda, misalnya skala, performa, atau keamanan.

Dalam sistem sederhana, Command dan Query bisa digabung. Tapi dalam sistem kompleks, pemisahan ini membuat sistem lebih efisien dan mudah dioptimasi.

Contoh sederhana (Rust):

// Command handler
fn confirm_order(order_repo: &mut impl OrderRepository, id: u64) {
    if let Some(mut order) = order_repo.find_by_id(id) {
        order.confirm();
        order_repo.save(order);
    }
}

// Query handler
fn get_order_details(order_repo: &impl OrderRepository, id: u64) -> Option<Order> {
    order_repo.find_by_id(id)
}

Kita bisa punya dua pipeline terpisah, satu untuk memproses perubahan, satu untuk membaca data (misalnya dari cache atau database yang dioptimalkan untuk query). CQRS sering dikombinasikan dengan Event Sourcing agar setiap perubahan bisa dilacak dengan mudah.

Memilih Pola yang Tepat

Tidak ada arsitektur yang “paling benar.” Pola yang ideal tergantung dari:

• Kompleksitas domain,

• Skala sistem,

• Kebutuhan integrasi, dan

• Tim yang mengelola.

Sebagai panduan umum:

• Gunakan Layered Architecture untuk sistem yang masih tumbuh.

• Gunakan Hexagonal Architecture jika ingin model domain benar-benar independen dari framework atau infrastruktur.

• Gunakan CQRS bila ada kebutuhan pemisahan beban baca/tulis yang signifikan.

Menghindari Arsitektur yang Membelenggu

Sering kali engineer terjebak pada arsitektur yang mereka anggap “suci”, sampai akhirnya domain model malah dikorbankan demi mematuhi struktur. DDD justru sebaliknya: arsitektur harus melayani domain, bukan sebaliknya.

Kuncinya adalah menjaga boundaries tetap jelas, tapi tidak kaku. Ketika model domain berkembang, arsitektur boleh ikut menyesuaikan, selama tujuannya sama: melindungi logika bisnis dari gangguan teknis.

Ringkasnya, Arsitektur Sebagai Penjaga Makna

Arsitektur bukan tentang folder, file, atau diagram. Ia tentang cara melindungi makna bisnis di dalam sistem kita.

Layer, port, dan adapter hanyalah alat untuk memastikan kode kita tetap bercerita tentang domain, bukan tentang framework. Karena pada akhirnya, sistem yang paling bertahan lama bukan yang paling modern arsitekturnya, tapi yang paling setia pada makna bisnis yang dilayaninya.

Referensi

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

Setelah kita membangun fondasi Domain Model, lengkap dengan Entity, Value Object, Aggregate, Repository, dan kawan-kawan, muncul pertanyaan besar berikutnya: “Bagaimana model domain kita tetap relevan ketika bisnis berubah?”

Di dunia nyata, bisnis tidak pernah diam. Aturan baru muncul, prioritas berubah, bahkan istilah yang dulu dianggap jelas bisa bergeser maknanya. Maka, Domain Model pun harus tumbuh dan berevolusi. Bab ini membahas bagaimana kita bisa menyempurnakan model tanpa membuat sistem runtuh.

Model Domain Bukan Arsitektur Sekali Jadi

Kesalahan umum dalam menerapkan DDD adalah menganggap domain model sebagai desain permanen. Padahal, model itu seharusnya hidup dan berubah mengikuti pemahaman baru tentang domain.

Khononov (2022) menekankan bahwa DDD bukan tentang mencari model yang sempurna di awal, melainkan mendekati pemahaman yang lebih baik seiring waktu. Setiap diskusi dengan ahli domain, setiap bug, dan setiap fitur baru bisa memperkaya model kita.

Bayangkan model domain seperti peta kota. Saat pertama kali dibuat, mungkin hanya berisi jalan utama. Tapi seiring waktu, kita tambahkan gang kecil, lampu merah, dan area baru — bukan karena peta awal salah, tapi karena pengetahuan kita bertambah.

Proses Refinement: Dari Model Kasar ke Model Tajam

1. Mulai dari Model Kasar

Pada awal proyek, buatlah model sederhana dulu — tidak masalah kalau belum lengkap. Fokus pada pemahaman dasar: apa saja konsep utama dan bagaimana mereka berhubungan.

Misalnya kita membangun sistem untuk pengiriman paket. Model awal bisa sesederhana ini:

struct Package {
    id: u64,
    status: String,
}

impl Package {
    fn deliver(&mut self) {
        self.status = "Delivered".to_string();
    }
}

Masih sederhana, tapi cukup untuk memulai percakapan dengan ahli domain.

2. Kembangkan Melalui Umpan Balik

Setiap kali bisnis atau stakeholder memberi masukan (“Bagaimana kalau pelanggan bisa menjadwalkan ulang pengiriman?”), kita ubah model agar mencerminkan realitas baru itu.

enum DeliveryStatus {
    Pending,
    InTransit,
    Delivered,
    Rescheduled(String), // alasan atau tanggal baru
}

struct Package {
    id: u64,
    status: DeliveryStatus,
}

Model berkembang mengikuti kebutuhan bisnis, bukan sebaliknya. Perubahan ini adalah bentuk refinement, bukan “refactor tanpa arah”.

3. Evaluasi Bahasa Umum (Ubiquitous Language)

Setiap istilah di model harus sama artinya bagi semua pihak, engineer, product owner, dan ahli domain.

Kalau tim mulai bilang “Shipment” di tempat yang seharusnya “Package”, itu tanda bahasa umum mulai kabur. Periksa model, ubah nama kelas, fungsi, dan variabel agar kembali konsisten dengan istilah bisnis yang terbaru.

Inilah kenapa DDD mendorong kode yang “bercerita seperti domain”-nya.

Pola Umum dalam Evolusi Model

1. Split dan Merge Aggregate

Saat sistem bertumbuh, aggregate yang dulu terasa ideal bisa jadi terlalu besar. Kita mungkin perlu memisahkannya agar tidak menimbulkan transaction contention atau performance bottleneck.

Misalnya awalnya kita punya Order yang juga menyimpan Payment dan Shipment di dalamnya. Tapi seiring waktu, tim pembayaran dan pengiriman berkembang terpisah.

Maka kita pisahkan menjadi tiga aggregate dengan batas yang jelas.

// Awalnya semua di Order
struct Order {
    id: u64,
    payment_status: String,
    shipment_status: String,
}

// Setelah displit
struct Order {
    id: u64,
}

struct Payment {
    order_id: u64,
    status: String,
}

struct Shipment {
    order_id: u64,
    tracking_code: String,
}

Kini setiap tim bisa berinovasi di domain-nya tanpa saling menunggu.

2. Mengubah Entity menjadi Value Object (atau sebaliknya)

Kadang sebuah objek awalnya dianggap penting secara identitas, tapi belakangan ternyata tidak.

Contoh: pada tahap awal, kita buat Address sebagai Entity karena kita pikir pengguna bisa memperbaruinya dan kita perlu menyimpannya secara unik. Tapi kemudian kita sadar bahwa Address hanya bagian dari Order dan tidak pernah digunakan secara terpisah.

Maka kita ubah menjadi Value Object.

#[derive(Clone, PartialEq, Eq)]
struct Address {
    street: String,
    city: String,
    postal_code: String,
}

Sebaliknya, jika suatu saat kita butuh melacak alamat pelanggan secara historis, Address bisa dipromosikan lagi menjadi Entity.

3. Menambah Domain Event untuk Dekoupling

Ketika sistem makin besar, modul-modul akan saling tergantung. Untuk mencegah kekacauan, kita bisa menambahkan Domain Event agar komunikasi antarmodul tidak saling menempel.

struct OrderCreated {
    order_id: u64,
}

struct SendEmailOnOrderCreated;

impl SendEmailOnOrderCreated {
    fn handle(event: &OrderCreated) {
        println!("Email konfirmasi untuk order {} dikirim!", event.order_id);
    }
}

Dengan event, Order tidak perlu tahu cara mengirim email, dan modul notifikasi bisa bereaksi secara independen. Ini membuat sistem lebih fleksibel dan siap tumbuh tanpa coupling berlebihan.

Evolusi yang Terarah, Bukan Reaktif

Menumbuhkan model domain bukan berarti “sering ganti struktur kode”. Tujuannya bukan perubahan semata, tapi perubahan yang memperdalam pemahaman kita terhadap domain.

Langkah idealnya seperti ini:

1. Temukan masalah di dunia nyata. Misalnya pengguna bingung dengan istilah “shipment” vs “delivery”.

2. Diskusikan dengan ahli domain. Pahami maknanya dalam konteks bisnis.

3. Perbarui bahasa umum. Ubah nama kelas atau entitas agar konsisten dengan istilah baru.

4. Refactor model. Pisahkan, gabungkan, atau ubah struktur sesuai pemahaman baru.

5. Uji dan validasi. Pastikan perubahan tidak merusak perilaku bisnis yang sudah benar.

Jika perubahan dilakukan lewat percakapan yang intens antara engineer dan ahli domain, model domain akan terus “mendekati kenyataan” seiring waktu.

Kesalahan Umum Saat Model Berevolusi

1. Refactor teknis tanpa konteks bisnis. Mengubah struktur hanya karena “terlihat lebih bersih”, padahal maknanya makin kabur.

2. Terlalu cepat memecah aggregate. Split boleh dilakukan, tapi pastikan memang ada kebutuhan bisnis atau beban transaksi nyata.

3. Mengabaikan bahasa umum. Nama-nama di kode harus tetap sejalan dengan istilah di dunia nyata, bukan dengan preferensi pribadi.

4. Tidak mencatat keputusan. Setiap perubahan besar di domain model sebaiknya punya alasan bisnis yang terdokumentasi.

Menumbuhkan Model Secara Aman

Dalam praktik modern, kita bisa menggunakan pendekatan seperti:

• Feature toggles, untuk mengaktifkan model baru tanpa mengganggu produksi.

• Event sourcing, agar perubahan model tidak kehilangan jejak historis.

• Migration scripts, untuk memindahkan data lama ke struktur baru dengan aman.

DDD tidak menentang perubahan, ia justru mengajarkan cara mengelolanya dengan sadar.

Akhirnya: Model yang Hidup

Domain model yang baik bukan yang paling indah diagramnya, tapi yang tetap bernapas bersama bisnisnya.

Ketika bisnis berubah, model pun ikut beradaptasi. Ketika istilah baru muncul, kode pun ikut menyesuaikan. Dan ketika engineer dan ahli domain berbicara, mereka bicara dalam bahasa yang sama, bukan lagi sekadar query, tapi makna.

Itulah esensi menghadapi kompleksitas: Bukan melawannya dengan abstraksi berlebihan, tetapi menjinakkannya dengan pemahaman yang terus bertumbuh.

Referensi

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

Dari Strategi ke Taktik

Dalam DDD, ada dua lapisan pendekatan: Strategic DDD dan Tactical DDD.
Strategic DDD membantu kita memetakan peta besar, membagi sistem menjadi domain, subdomain, dan bounded context.
Sementara Tactical DDD berbicara tentang bagaimana kita membangun isi di dalam satu bounded context itu.

Kalau Strategic DDD seperti membuat denah kota, maka Tactical DDD adalah merancang bangunan di dalam tiap distrik: siapa penghuni, bagaimana alurnya, dan aturan apa yang berlaku di dalamnya.

Domain Model: Jantung dari DDD

Sebuah domain model bukan sekadar diagram UML atau tabel database.
Ia adalah representasi konseptual dari cara bisnis bekerja, diterjemahkan ke dalam kode, menggunakan bahasa yang sama dengan yang digunakan oleh para ahli domain.

Model ini bukan hanya soal data structure, tapi juga soal perilaku (behavior) dan aturan (rules) yang melekat di dalamnya.

Contoh sederhana:
Bayangkan kita membuat sistem untuk toko online. Ada entitas Order, tapi Order bukan cuma tabel dengan kolom id, total, dan status.
Ia harus tahu bagaimana:

• menambahkan item,

• menghitung total,

• memastikan tidak ada duplikasi produk,

• dan kapan pesanan bisa dikonfirmasi.

Model yang baik berarti kode kita bicara seperti bisnisnya.

Entity

Salah satu elemen paling penting dari domain model adalah Entity, sebuah objek yang punya identitas unik dan bisa berubah seiring waktu.

Misalnya, User dengan ID 123 tetap sama orangnya meski alamat atau emailnya berubah.
Yang menentukan dirinya adalah identitas, bukan nilainya.

struct User {
    id: u64,
    name: String,
    email: String,
}

impl User {
    fn change_email(&mut self, new_email: String) {
        self.email = new_email;
    }
}

Di sini User adalah Entity karena kita mengenalinya lewat id.
Ketika change_email() dipanggil, objek ini masih “orang yang sama”.

Value Object

Berbeda dengan Entity, Value Object tidak punya identitas.
Ia hanya penting karena nilainya. Dua objek yang nilainya sama dianggap sama.

Coba pikirkan Money, Address, atau DateRange.
Kalau kamu punya Money { amount: 100, currency: “USD” }, itu identik dengan objek lain yang punya nilai sama.

#[derive(Debug, Clone, PartialEq, Eq)]
struct Money {
    amount: f64,
    currency: String,
}

Value Object biasanya immutable, artinya nilainya tidak diubah, tapi dibuat baru saat ada perubahan.
Pendekatan ini membuat kode lebih aman dan mudah diprediksi.

Aggregate

Saat bisnis mulai kompleks, satu entitas tidak lagi cukup.
Kita butuh sekumpulan entitas dan value object yang bekerja bersama dalam satu batas konsistensi.
Inilah yang disebut Aggregate.

Aggregate adalah kumpulan objek yang dikelola sebagai satu kesatuan logis, dengan satu titik masuk utama yang disebut Aggregate Root.

struct OrderItem {
    product_id: u64,
    quantity: u32,
}

struct Order {
    id: u64,
    items: Vec<OrderItem>,
}

impl Order {
    fn add_item(&mut self, product_id: u64, quantity: u32) {
        self.items.push(OrderItem { product_id, quantity });
    }

    fn total_items(&self) -> usize {
        self.items.len()
    }
}

Order di atas adalah Aggregate Root — semua perubahan terhadap OrderItem harus melalui Order.
Aggregate membantu menjaga aturan bisnis tetap konsisten di dalam batasnya.

Repository

Domain Model tidak seharusnya tahu tentang database atau API.
Tapi tentu kita tetap perlu menyimpan data.
Untuk itu, DDD memperkenalkan Repository.

Repository berfungsi sebagai “pintu keluar masuk” Aggregate.
Dari sisi domain, Repository terlihat seperti koleksi di memori, meski di baliknya mungkin ada SQL, file, atau service eksternal.

trait OrderRepository {
    fn save(&self, order: &Order);
    fn find_by_id(&self, id: u64) -> Option<Order>;
}

Dengan pola ini, domain tetap bersih dari detail teknis.
Kita bisa mengganti penyimpanan dari SQLite ke PostgreSQL tanpa mengubah logika bisnis sedikit pun.

Domain Service

Kadang kita menemukan logika bisnis yang tidak cocok dimasukkan ke satu entitas mana pun.
Misalnya, proses transfer uang antar akun: melibatkan dua Account, tapi tidak ada satu pun yang benar-benar “memiliki” logika itu.

Inilah peran Domain Service, tempat untuk menaruh logika lintas entitas.

struct Account {
    id: u64,
    balance: f64,
}

struct TransferService;

impl TransferService {
    fn transfer(from: &mut Account, to: &mut Account, amount: f64) {
        if from.balance >= amount {
            from.balance -= amount;
            to.balance += amount;
        }
    }
}

Domain Service tetap bagian dari domain layer, bukan service teknis seperti API handler atau queue worker.
Ia merepresentasikan aksi bisnis, bukan infrastruktur.

Factory

Membuat entitas kadang tidak sesederhana memanggil new().
Ada validasi, aturan bisnis, atau dependensi lain.
Di sinilah Factory digunakan.

Factory bertugas membangun objek kompleks dengan aturan bisnis yang benar sejak awal.

struct OrderFactory;

impl OrderFactory {
    fn create_new(items: Vec<OrderItem>) -> Order {
        assert!(!items.is_empty(), “Order harus punya minimal satu item”);
        Order { id: 0, items }
    }
}

Factory mencegah kita membuat objek domain dalam keadaan “tidak valid”.
Ia seperti dapur yang memastikan masakan sudah matang sebelum dihidangkan.

Domain Event

Dalam kehidupan nyata, setiap sistem bisnis penuh dengan peristiwa: pesanan dibuat, pembayaran diterima, stok habis, dsb.
DDD merepresentasikan semua itu lewat Domain Event.

Event adalah sinyal bahwa sesuatu yang penting sudah terjadi di dalam domain.
Biasanya diberi nama dengan bentuk lampau: OrderCreated, PaymentReceived.

struct OrderCreated {
    order_id: u64,
    timestamp: u64,
}

Event bisa dikirim ke bagian lain dari sistem (misalnya ke modul pengiriman atau notifikasi) tanpa membuat coupling langsung antar komponen.
Hasilnya: sistem lebih fleksibel dan modular.

Menghadapi Kompleksitas

Setiap sistem yang tumbuh pasti akan menjadi kompleks.
Tactical DDD memberi kita alat untuk mengelola kompleksitas itu, bukan menyingkirkannya.

• Entity dan Value Object membantu kita berpikir dalam istilah bisnis, bukan tabel.

• Aggregate menjaga aturan tetap konsisten.

• Repository dan Factory memisahkan logika domain dari teknis.

• Domain Service dan Event membuat sistem bisa berkembang tanpa kekacauan.

Inilah inti filosofi DDD: “Kode bukan cuma alat, tapi cerminan dari cara kita memahami bisnis.”

Ketika model domain dibuat dengan benar, engineer tidak hanya menulis kode, mereka mengkodekan pengetahuan bisnis yang bisa bertahan bertahun-tahun, bahkan ketika framework atau teknologi berubah.

Referensi

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

Business Logic

Logika bisnis (business logic) adalah bagian dari sistem yang menentukan bagaimana data diproses sesuai aturan dan tujuan bisnis.

Secara definisi:

Business logic adalah sekumpulan keputusan, kalkulasi, kondisi, dan alur kerja yang menjelaskan bagaimana bisnis seharusnya beroperasi dalam konteks sistem perangkat lunak.

Contoh:

• Jika saldo rekening < 0 → tolak transaksi.

• Jika pelanggan sudah bayar → ubah status pesanan menjadi “confirmed.”

• Jika total belanja > 1 juta → berikan diskon 10%.

Semua ini bukan “aturan pemrograman umum,” tapi cara bisnis tertentu berjalan.
Karena itu, business logic berbeda dari technical logic (seperti validasi input, autentikasi pengguna, caching, dll.).

Intinya: logika bisnis = perilaku sistem yang mencerminkan keputusan bisnis.

Business Rules

Istilah Business Rules dan Business Logic ini sering tertukar, padahal secara konsep ada perbedaan:

• Business Rules

  • Ciri utama: Prinsip atau kebijakan yang didefinisikan oleh organisasi, misalnya menjelaskan apa yang boleh dan tidak boleh terjadi di dunia nyata.

  • Contoh: Setiap transaksi harus memiliki nomor faktur unik.

• Business Logic

  • Ciri utama: Implementasi teknis dari aturan-aturan tersebut di dalam sistem.

  • Contoh: fn generate_invoice_id() memastikan nomor faktur tidak duplikat.

Singkatnya:

• Business rules = “aturan permainan” (bersifat deklaratif).

• Business logic = “cara memainkan permainan itu di sistem” (bersifat prosedural).

Dalam DDD, keduanya sama-sama penting:

• Aturan bisnis berasal dari pengetahuan ahli domain (domain expert).

• Logika bisnis diimplementasikan di kode (biasanya di entitas atau service dalam domain model).

Transaction Script

Secara definisi, Transaction Script adalah pola arsitektur di mana setiap operasi bisnis diimplementasikan sebagai satu prosedur atau fungsi tunggal.
Istilah aslinya berasal dari Patterns of Enterprise Application Architecture oleh Martin Fowler (2003).

Definisi: “Transaction Script organizes business logic by procedures where each procedure handles a single request from the presentation.”
— Martin Fowler, P of EAA, 2003.

Dengan kata lain:

• Setiap use case bisnis (misal “proses pembayaran”, “buat laporan”, “import data”) ditulis sebagai satu skrip atau fungsi.

• Logika bisnis disusun secara imperatif (langkah demi langkah).

• Tidak ada objek domain yang rumit — biasanya hanya sekumpulan operasi database.

Analogi: seperti membuat resep dapur dalam satu lembar kertas, semua langkahnya berurutan: ambil bahan, masak, sajikan. Simpel, tapi sulit dipakai ulang kalau resep makin kompleks.

Khononov (2022) menjelaskan bahwa Transaction Script mengorganisir logika bisnis ke dalam prosedur terpisah. Setiap prosedur (atau fungsi) menangani satu permintaan atau operasi bisnis.

Misalnya, fungsi process_payment() yang hanya fokus menyelesaikan satu transaksi pembayaran. Pendekatan ini gampang dipahami dan minim abstraksi. Contohnya, bayangkan kita punya daftar pekerjaan (job) yang perlu diproses satu per satu:

fn process_jobs(db: &Database) {
    db.start_transaction();
    if let Some(job) = db.load_next_job() {
        let data = std::fs::read_to_string(&job.source).unwrap();
        let result = convert_to_xml(&data);
        std::fs::write(&job.destination, result).unwrap();
        db.mark_complete(job.id);
    }
    db.commit();
}

Kode di atas menunjukkan satu prosedur sederhana: mulai transaksi, baca job berikutnya, ubah data, simpan hasil, lalu commit. Jika ada kesalahan di tengah, sistem harus rollback agar data tetap konsisten.

Khononov menegaskan pentingnya perilaku transaksional di setiap skrip: operasi harus sukses seluruhnya atau gagal tanpa meninggalkan kondisi setengah jadi. Karena itu, pola Transaction Script cocok untuk subdomain pendukung atau tugas ETL (Extract-Transform-Load) sederhana. Sebagai contoh, sinkronisasi data dari satu sistem ke sistem lain bisa diimplementasikan dengan skrip seperti di atas.

Kapan pakai Transaction Script? Beberapa poin penting:

• Cocok untuk subdomain pendukung atau generik di mana logika bisnisnya prosedural (misal batch job, laporan, sinkronisasi).

• Sederhana dan cepat: minim abstraksi, performa tinggi karena langsung panggil database (atau penyimpanan).

• Hati-hati: Jika logika bisnis makin kompleks, skrip terpisah cenderung duplikasi kode dan kesulitan pemeliharaan. Khononov bahkan menyebut pattern ini sering dianggap antipola (antipattern) karena bisa jadi “big ball of mud” jika dipakai di domain inti yang rumit. Jadi, jangan pakai Transaction Script untuk core subdomain yang punya banyak aturan bisnis, karena pola ini tidak tahan dengan kompleksitas tinggi.

Antipattern Arsitektur Big Ball of Mud

Ini adalah antipattern arsitektur yang menggambarkan sistem tanpa struktur yang jelas.

Definisi: “A Big Ball of Mud is a haphazardly structured system, tangled, and difficult to maintain.”
— Foote & Yoder, 1997.

Sederhananya:

• Semua kode bercampur tanpa batas yang jelas.

• Tidak ada pemisahan logika bisnis, data, dan presentasi.

• Setiap perubahan kecil bisa merusak bagian lain.

Dalam konteks pembahasan di atas:

Jika kita memaksa memakai Transaction Script atau Active Record untuk domain yang kompleks (seperti core subdomain), cepat atau lambat sistem akan jadi Big Ball of Mud.

Kenapa? Karena fungsi-fungsi akan saling memanggil, logika duplikat di mana-mana, dan tidak ada satu model mental yang jelas tentang “bagaimana bisnis bekerja” di dalam kode.

Active Record

Active Record juga berasal dari buku Fowler yang sama, dan definisinya adalah:

Definisi: “An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.”
— Martin Fowler, P of EAA, 2003.

Artinya:

• Setiap baris di tabel database direpresentasikan oleh sebuah objek.

• Objek itu “aktif” karena bisa menyimpan (save()), memperbarui (update()), atau menghapus (delete()) dirinya sendiri.

• Kadang juga memuat logika bisnis sederhana, seperti validasi atau penghitungan kecil.

Analogi: seperti lembar Excel di mana tiap baris bisa langsung “menyimpan dirinya ke server” begitu kita ubah isinya.

Active Record biasanya lebih rapi dari Transaction Script karena sudah mulai ada objek dan data berelasi, tapi belum punya pemisahan yang jelas antara data dan aturan bisnis.

Pola ini diperkenalkan oleh Fowler dan disitir Khononov (2022) sebagai objek yang “membungkus satu baris di tabel database, mengenkapsulasi akses database, dan menambah logika bisnis di data tersebut”. Artinya, setiap entitas data (misalnya baris User di tabel) direpresentasikan oleh sebuah objek yang punya metode sendiri, termasuk operasi save() atau update() ke database.

Active Record cocok ketika logika bisnis masih sederhana, tapi struktur datanya relatif rumit (misal relasi banyak-ke-banyak). Contohnya, kalau kita punya struct Rust User:

struct User {
    id: u32,
    name: String,
    email: String,
}

impl User {
    fn save(&self, conn: &DbConnection) {
        // Contoh sederhana: INSERT atau UPDATE ke DB
        conn.execute(”INSERT INTO users ...”, &[&self.name, &self.email]);
    }
    fn increment_logins(&mut self, conn: &DbConnection) {
        self.logins += 1;
        self.save(conn);
    }
}

Di sini, User bertindak sebagai active record: ia menyimpan datanya (id, name, dll.) dan punya method save() untuk persist ke database. Jika kita perlu modifikasi data kompleks, kita manipulasi objek User dan panggil user.save(conn) untuk update.

Menurut Khononov, tujuan pola ini adalah mengenkapsulasi kompleksitas pemetaan antara object ke skema database. Dibanding Transaction Script, skema Active Record menyediakan objek-objek khusus yang memuat data dan operasi CRUD mereka sendiri.

Kapan pakai Active Record? Beberapa poin:

• Logika masih sederhana (CRUD, validasi input ringan) tapi datanya lebih struktur.

• Berguna di subdomain pendukung/generik yang butuh konversi data kompleks ke model aplikasi.

• Intinya: Active Record adalah Transaction Script yang “hidup” – yaitu setiap operasi bisnis masih dilakukan di luar objek, tapi objek data punya save() sendiri. Ini punya kekurangan: logika bisnis tetap tersebar di layanan/prosedur, jadi sering disebut anemic domain model. Maka jangan gunakan di core subdomain yang seharusnya punya domain model penuh (full domain model).

Ringkasnya, bagian ini memberikan pemahaman bahwa untuk kasus sederhana kita bisa pakai Transaction Script atau Active Record. Keduanya ringan dan cepat diimplementasi, tapi terbatas pada logika sederhana di subdomain pendukung. Untuk core subdomain dengan banyak aturan, kita akan membahas pada pola Domain Model berikutnya.

Anemic Domain Model

Istilah ini juga dari Martin Fowler, dan Khononov menyinggungnya saat membandingkan Active Record dengan Domain Model.

Definisi: “Anemic Domain Model is a domain model where the business logic is absent and resides in services instead of the entities themselves.”
— Martin Fowler, 2003.

Artinya:

• Objek domain hanya menyimpan data (getter & setter).

• Logika bisnis tersebar di service/fungsi lain.

• Secara teknis modelnya ada, tapi secara semantik “kosong”.

Contoh dalam Rust:

struct Order {
    id: u32,
    total: f64,
    status: String,
}

fn confirm(order: &mut Order) {
    if order.total > 0.0 {
        order.status = “Confirmed”.to_string();
    }
}

Objek Order di sini tidak tahu apa-apa tentang bisnisnya sendiri.
Segala logika berada di luar (confirm()). Akibatnya, aturan bisnis bisa dengan mudah tersebar dan bertentangan.

DDD menolak pola ini karena tujuan DDD adalah memusatkan logika bisnis di dalam domain model, agar kode benar-benar mencerminkan pemikiran bisnis.

Full Domain Model

Dalam DDD, domain model penuh, istilah aslinya adalah “Rich Domain Model” atau “Full-Fledged Domain Model”.

Definisi: “A rich domain model is one where domain objects encapsulate both data and behavior, enforcing business rules internally.”
— Evans, Domain-Driven Design, 2004.

Bedanya dengan anemic domain model berdasarkan karakteristik:

• Rich (Full) Domain Model

  • Data dan perilaku: Digabung di entitas.

  • Aturan Bisnis: Ditegakkan di dalam entitas.

  • Keterwakilan domain: Kuat, selaras dengan bahasa bisnis.

  • Cocok untuk: Core subdomain.

• Anemic Domain Model

  • Data dan perilaku: Terpisah.

  • Aturan Bisnis: Tersebar di service luar.

  • Keterwakilan domain: Lemah, cenderung CRUD.

  • Cocok untuk: Supporting/generic subdomain.

Jadi ketika Khononov menulis bahwa “core subdomain seharusnya memiliki domain model penuh”, maksudnya adalah:

Subdomain yang menjadi keunggulan utama bisnis harus diimplementasikan dengan rich domain model, agar aturan bisnis dan konsep bisnis benar-benar hidup di dalam kode, bukan di spreadsheet, dokumen, atau service-service longgar.

Domain Model Berdasarkan Pola yang Cocok

Ada spektrum kompleksitas yang mempengaruhi pemilihan domain model yang cocok:

• Kondisi domain sangat sederhana (ETL, batch job, CRUD data referensi)

  • Pola yang cocok: Transaction Script.

  • Karena tidak perlu model atau logika kompleks.

• Kondisi domain sederhana tapi punya struktur data berelasi

  • Pola yang cocok: Active Record.

  • Karena sedikit OO, tapi mudah dan cepat.

• Kompleks dengan aturan bisnis yang dinamis

  • Pola yang cocok: Rich Domain Model.

  • Karena logika terpusat di entitas & aggregate.

• Butuh audit / histori

  • Pola yang cocok: Event-Sourced Domain Model.

  • Karena Domain Model + Event Sourcing.

Melihat Kembali Subdomain Pendukung (supporting subdomain)

Di atas banyak dibahas bahwa keduanya terbatas pada logika sederhana di subdomain pendukung. Kita lihat kembali klasifikasi subdomain pada DDD (Khononov, 2022):

• Core Subdomain

  • Karakteristik: Menjadi sumber keunggulan kompetitif bisnis. Kompleks, sering berubah, butuh inovasi tinggi.

  • Fokus solusi: Perlu desain DDD mendalam, domain model penuh, investasi besar.

• Supporting Subdomain

  • Karakteristik: Mendukung operasional inti, tapi tidak membedakan bisnis dari kompetitor. Biasanya sederhana.

  • Fokus solusi: Gunakan solusi pragmatis (Transaction Script, Active Record, atau framework siap pakai)

• Generic Subdomain

  • Karakteristik: Umum dipakai semua bisnis (contoh: autentikasi, log aktivitas).

  • Fokus solusi: Lebih baik dibeli atau pakai library standar.

Sederhananya:

• Supporting subdomain masih penting untuk bisnis, tapi tidak menentukan keberhasilan utama.

• Karena kompleksitasnya rendah dan nilai strategisnya kecil, maka kita tidak perlu investasi arsitektur rumit seperti Domain Model penuh.

• Inilah kenapa Transaction Script dan Active Record cocok: cepat dibuat, mudah dipelihara, cukup stabil.

Sebaliknya, core subdomain biasanya punya banyak aturan bisnis, ketergantungan lintas fungsi, dan terus berubah.

Data & Logika Bisnis

Pernyataan “pemisahan antara data dan logika bisnis“ ini sering muncul dalam konteks arsitektur software, misalnya Separation of Concerns.

Artinya: Data (apa yang disimpan) dan logika bisnis (apa yang dilakukan terhadap data itu) tidak seharusnya bercampur dalam satu tempat.

Contoh salah:

fn save_order_to_db(order_id: u32, total: f64) {
    // ... query ke DB ...
    if total > 1000000.0 {
        // logika bisnis diselipkan di sini
        println!(”Diskon 10%”);
    }
}

Contoh benar:

struct Order {
    id: u32,
    total: f64,
}

impl Order {
    fn apply_discount(&mut self) {
        if self.total > 1000000.0 {
            self.total *= 0.9;
        }
    }
}

fn save_order_to_db(order: &Order) {
    // hanya urusan penyimpanan
}

Pada contoh benar, fungsi save_order_to_db() hanya fokus pada data persistence, sedangkan apply_discount() berisi logika bisnis.
Keduanya terpisah untuk memudahkan pengujian, refaktor, dan perubahan aturan bisnis tanpa merusak cara penyimpanan data.

Pemisahan antara data, logika bisnis, dan presentasi adalah prinsip dasar arsitektur aplikasi, sering disebut sebagai three-layer (or three-tier) architecture.

• Presentation layer

  • Tugas utama: Menampilkan data kepada pengguna dan menerima input.

  • Contoh dalam aplikasi: Antarmuka pengguna (UI), web page, REST API endpoint, CLI.

• Business Logic layer

  • Tugas utama: Menjalankan aturan dan keputusan bisnis.

  • Contoh dalam aplikasi: Fungsi domain, service, entitas, aggregate.

• Data Access layer atau Persistence Layer

  • Tugas utama: menyimpan dan mengambil data.

  • Contoh dalam aplikasi: Database, ORM, repository.

Dalam konteks arsitektur, “presentation layer” mencakup segala sesuatu yang berhubungan dengan interaksi pengguna atau sistem lain. Misalnya:

• UI web atau mobile,

• API endpoint (yang melayani HTTP request),

• atau bahkan CLI untuk admin.

Presentasi tidak boleh tahu detail logika bisnis, cukup memanggil fungsinya saja.
Contoh:

// presentation layer
fn handle_checkout_request(user_input: CheckoutData) {
    let mut order = Order::new(user_input.items);
    order.apply_discount(); // business logic
    repository::save(order); // data layer
}

Ketiganya punya tanggung jawab berbeda:

• Presentation layer: berbicara dengan pengguna atau sistem lain.

• Business logic layer: memutuskan apa yang boleh atau harus terjadi.

• Data layer: mengelola penyimpanan (database, cache, dsb).

Prinsip ini disebut Separation of Concerns: memisahkan tanggung jawab agar sistem lebih modular dan mudah berkembang.

Referensi

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

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.

Contohnya dari buku Khononov (2022): perusahaan telemarketing; tim marketing memandang “lead” sebagai sekadar notifikasi ketika seorang prospek menunjukkan minat. Tapi tim sales melihat “lead” sebagai proses penjualan yang lengkap, dari awal sampai konversi – sebuah entitas yang jauh lebih kompleks.

Masalahnya, jika kita mencoba membuat satu model tunggal yang menampung dua pandangan berbeda ini, model itu bakal terlalu besar dan kompleks, atau malah terlalu disederhanakan sehingga tidak memenuhi kebutuhan salah satu tim. Prefix seperti “marketingLead” dan “salesLead” tidak membantu banyak karena tetap membingungkan pemakai bahasa (orang cenderung tidak pakai istilah seperti itu dalam obrolan sehari-hari).

Solusi DDD-nya adalah Bounded Context: kita memecah bahasa umum tadi menjadi beberapa bahasa yang lebih kecil, masing-masing dipakai dalam konteks tertentu.

Secara harfiah, “bounded context” berarti “konteks yang memiliki batas.”
Kata bounded artinya “dibatasi,” dan context artinya “lingkungan makna” atau “tempat di mana istilah-istilah punya arti tertentu.”

Dalam konteks DDD, Bounded Context adalah batas eksplisit di mana satu model domain dan bahasa umum (ubiquitous language) berlaku secara konsisten.
Di dalam batas itu, istilah, aturan, dan logika bisnis punya arti yang jelas dan tidak membingungkan. Tapi di luar batas itu, istilah yang sama bisa berarti lain, dan itu tidak apa-apa.

Dalam contoh tadi, kita bisa punya dua bounded context: Marketing dan Sales. Di tiap konteks ini, istilah “Lead” hanya punya satu arti saja sesuai kebutuhan konteks itu. Dengan cara ini, tidak ada kebingungan di dalam kode – misalnya marketing::Lead bisa kita definisikan terpisah dari sales::Lead dalam kode Rust:

mod marketing {
    #[derive(Debug)]
    struct Lead {
        contact_info: String,
        // ...
    }
}
mod sales {
    #[derive(Debug)]
    struct Lead {
        customer_id: u32,
        // ...
    }
}

Dengan model seperti di atas, marketing::Lead dan sales::Lead mengandung arti berbeda meski namanya sama. Ini menggambarkan bounded context: setiap modul atau bagian sistem memiliki bahasanya sendiri yang konsisten di dalam konteksnya. Lalu, kapan kita berhenti memecah konteks? Sama seperti peta, tiap model punya batas manfaatnya. Bounded context adalah batas pemakaiannya: setiap model hanya berguna dalam domain masalah yang spesifik. Peta jalan tidak bisa dipakai di laut; begitupun model “Lead” marketing tidak berguna untuk logika sales.

DDD mengajarkan bahwa kejelasan makna lebih penting daripada keseragaman istilah.
Dengan bounded context:

• Tim bisa bekerja secara independen,

• Model mereka tetap konsisten di dalam konteksnya,

• Dan integrasi antar konteks bisa diatur lewat pola yang eksplisit (seperti Shared Kernel atau Anticorruption Layer), yang akan dibahas selanjutnya.

Menentukan ukuran bounded context adalah keputusan desain strategis. Semakin luas batasannya, semakin sulit menjaga konsistensi model. Kadang berbagi konteks besar lebih mudah karena integrasi lebih sederhana, tapi terkadang kita perlu memecahnya lagi (misalnya tim terpisah, atau performa terpisah). Aturan umumnya: jika sekumpulan use case (kasus penggunaan) berhubungan erat dengan data yang sama, biarkan saja dalam satu bounded context. Jangan memecah fitur yang koheren menjadi beberapa konteks tanpa alasan kuat, karena setiap kali fungsionalitas berubah, semua konteks yang terpisah harus diubah bersamaan – bikin repot!

Perbedaan subdomain (yang dibahas di artikel memahami domain bisnis) dengan bounded context penting disini. Subdomain berasal dari analisis bisnis (sesuai strategi perusahaan), sedangkan bounded context kita rancang untuk software. Sebagai engineer, kita bebas menentukan batasan model kita. Kadang kita menyelaraskan: satu subdomain inti bisa jadi satu bounded context. Kadang tidak: kita bisa memiliki beberapa model (bound context) untuk satu subdomain untuk tujuan yang berbeda. Misalnya, subdomain akuntansi bisa punya konteks terpisah untuk laporan finansial dan satu lagi untuk perhitungan pajak, dengan model yang berbeda untuk masing-masing.

Selain sebagai batas konsep, bounded context juga menjadi batas fisik dan kepemilikan dalam pengembangan. Secara fisik, tiap bounded context idealnya diimplementasikan sebagai layanan atau modul terpisah sehingga bisa dipilih teknologi yang cocok, dan diedarkan sendiri. Secara tim, satu bounded context hanya diurus satu tim saja; tidak boleh dua tim bekerja di kode yang sama. Ini mencegah asumsi tersembunyi antar tim. Dengan bounded context, kita memetakan struktur organisasi dan arsitektur sistem dalam satu alat yang sama.

Referensi

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

Pengetahuan domain (domain knowledge) adalah semua pemahaman tentang dunia nyata yang sedang kita coba pecahkan lewat sistem/software yang kita bangun. Sistem/software adalah representasi digital dari realitas bisnis. Karena itu dalam DDD, langkah pertama adalah menemukan atau menggali pengetahuan domain, supaya tim engineering dan bisnis punya pemahaman yang sama tentang apa yang sebenarnya ingin diselesaikan.

Intinya, setiap kali kita mengembangkan sistem perangkat lunak, kita sebenarnya memecahkan masalah bisnis yang dihadapi perusahaan (misalnya, mengoptimalkan pengiriman paket FedEx atau melacak stok toko). Masalah bisnis ini rumit dan biasanya hanya diketahui oleh para ahli domain. Jika kita tidak bisa menggunakan istilah mereka, kita akan mudah salah paham tentang kebutuhan sistem.

Masalah umum dalam proyek pengembangan adalah hambatan komunikasi. Pengetahuan domain sering “diterjemahkan” berkali-kali: dari ahli domain (domain expert) ke analis, lalu ke dokumen syarat, lalu ke desain sistem, lalu ke kode program. Setiap penerjemahan seperti permainan bisik-bisikan: informasi penting bisa hilang atau bias. Akibatnya, tim developer bisa saja membangun solusi yang salah karena tidak sepenuhnya memahami masalah aslinya.

Ahli domain (domain expert) adalah orang yang benar-benar paham seluk-beluk dunia nyata yang sedang kita pecahkan lewat sistem/software. Mereka tidak harus bisa coding, tapi mereka tahu kenapa sesuatu harus dilakukan seperti itu dalam bisnis.

Untuk menghindari informasi penting yang hilang atau bias, DDD memperkenalkan konsep Ubiquitous Language, satu set istilah tunggal yang digunakan oleh semua pihak (pengembang, analis, ahli domain, bahkan UI/UX) ketika membicarakan domain bisnis. Artinya, jangan lagi menggunakan jargon teknis di antara ahli bisnis (business expert). Gunakan hanya istilah bisnis yang mudah dipahami semua orang. Misalnya, ketika merancang sistem manajemen kampanye iklan, semua orang harus sepakat pada frase seperti “kampanye”, “materi iklan”, “tayang”, bukan “iframe”, “record SQL” atau istilah IT lainnya yang mungkin tidak dipahami pihak bisnis.

Fase penemuan pengetahuan domain terjadi lewat kolaborasi aktif antara engineer, ahli domain, dan ahli bisnis.
Tujuannya bukan cuma mengumpulkan requirement, tapi menyatukan cara berpikir tentang masalah dan solusinya.

• Ahli bisnis membawa visi dan prioritas (“kita ingin menurunkan waktu pengiriman”).

• Ahli domain menjelaskan realitas dan batasan teknis di lapangan (“kalau hujan, kurir butuh rute alternatif”).

• Engineer menerjemahkan semua itu menjadi model domain dan bahasa umum yang bisa diimplementasikan di software.

Dengan analogi:

Ahli bisnis membantu menentukan arah perahu, ahli domain membantu menavigasi jalur aman, dan engineer membantu membangun perahunya.

Ubiquitous Language harus konsisten dan tepat. Setiap istilah harus punya satu arti yang jelas, tidak boleh ambigu atau punya sinonim ganda. Misalnya, jika di bisnis asuransi kata “polis” bisa berarti aturan regulasi atau kontrak asuransi, dalam bahasa umum kita harus meluruskannya menjadi dua istilah terpisah: “peraturan regulasi” dan “kontrak asuransi”. Begitu juga kita sebaiknya tidak mencampur istilah seperti “user”, “visitor”, dan “account” jika ternyata memiliki makna berbeda dalam bisnis, setiap istilah harus dipakai secara khusus sesuai konteks. Dengan begitu, tidak ada salah paham antar tim.

Secara keseluruhan, kita sebenarnya sedang membuat model domain bisnis menggunakan bahasa umum itu. Model di sini diibaratkan seperti peta: kita tidak menggambar semua detail bumi, hanya memilih aspek yang relevan untuk tujuan tertentu (misalnya peta jalan, peta metro, atau peta cuaca). Begitu pula model sistem. Contohnya, untuk sistem kampanye iklan, kita mungkin butuh entitas Campaign dengan field seperti id, is_published, dan daftar placements. Dalam kode Rust, misalnya:

struct Campaign {
    id: u32,
    title: String,
    placements: Vec<Placement>,
    is_published: bool,
    // field lainnya sesuai kebutuhan bisnis...
}

Model domain (domain model) adalah representasi mental dari bagaimana dunia bisnis bekerja, yang kita tuangkan ke dalam bentuk istilah, diagram, dan akhirnya kode. Model domain bukan sekadar diagram UML atau ERD, melainkan gabungan dari konsep, relasi, dan aturan bisnis yang disepakati oleh tim.
Contoh lainnya dalam sistem e-commerce:

• Entitas: Order, Product, Customer, Payment

• Relasi: Order berisi beberapa Product, dan terhubung dengan satu Customer

• Aturan bisnis: Order tidak bisa dikonfirmasi jika Payment belum berhasil

Model domain adalah jantung DDD, karena semua keputusan desain dan kode mengacu ke sana.

Ubiquitous language adalah kosakata yang disepakati bersama oleh semua pihak (developer, ahli domain, manajer, tester) untuk membicarakan hal-hal di dalam model domain.

• Kalau model domain berisi konsep dan relasi,
  maka bahasa umum adalah kata-kata yang dipakai untuk menyebut konsep-konsep itu.

• Bahasa umum harus muncul di percakapan, dokumentasi, dan kode.

Contoh:

• Kalau di bisnis disebut “pesanan dikonfirmasi”, maka di kode pun sebaiknya ada order.confirm() — bukan flag = true atau set_status(1).

• Kalau ahli domain menyebut “pengiriman gagal karena kurir kehabisan slot”, maka model domain perlu entitas CourierSchedule, bukan sekadar delivery_attempts.

Dengan begitu, software benar-benar mencerminkan cara berpikir orang bisnis, bukan sekadar logika teknis.

Dengan analogi:

Bayangkan kamu main “pesan berantai” di masa kecil, seseorang berbisik ke orang kedua, lalu diteruskan ke orang ketiga, dan seterusnya. Di akhir, pesan sering berubah total dari yang aslinya.

Nah, dalam proyek software tradisional:

1. Ahli domain (domain expert) menjelaskan masalah ke analis bisnis.

2. Analis menulis dokumen requirement.

3. Dokumen itu dibaca arsitek atau developer.

4. Developer menulis kode berdasarkan interpretasinya.

Di setiap tahap, arti bisa melenceng sedikit demi sedikit.
Hasil akhirnya: software yang secara teknis benar tapi secara bisnis bisa salah.

Dengan DDD, kita memotong rantai itu: developer bicara langsung dengan ahli domain, memakai bahasa umum yang sama, sehingga model yang tertulis di kode benar-benar mewakili pemahaman bisnis yang sebenarnya. Hasilnya, pengembang dapat membuat kode (dan model data) yang betul-betul sesuai dengan pemikiran dan kebutuhan bisnis, sehingga sedikit konflik ketika kebutuhan berubah.

Model data biasanya berarti struktur penyimpanan, tabel di database, kolom, tipe data, relasi. Fokusnya: bagaimana data disimpan dan diakses secara efisien.
Contohnya:

struct OrderRow {
    id: i64,
    customer_id: i64,
    status_code: i32,
    created_at: DateTime<Utc>,
}

Sedangkan model domain berfokus pada logika dan aturan bisnis, bagaimana entitas berperilaku dan saling berinteraksi.
Contohnya:

struct Order {
    id: OrderId,
    customer: CustomerId,
    items: Vec<OrderItem>,
    status: OrderStatus,
}

impl Order {
    fn confirm(&mut self) -> Result<(), &’static str> {
        if self.items.is_empty() {
            Err(”order must have items before confirmation”)
        } else {
            self.status = OrderStatus::Confirmed;
            Ok(())
        }
    }
}

Dalam DDD, model domain adalah pusatnya, sedangkan model data hanyalah salah satu cara menyimpan informasi dari model domain.
Jadi, relasi antara keduanya seperti: “Model domain menjelaskan makna bisnisnya, model data menyimpan faktanya.”

Kalo mau tahu lebih jauh mengenai pemrograman Rust bisa belajar di kelas Belajar Pemrograman Rust untuk Pemula di Dicoding.

Referensi

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

Misalnya, FedEx bergerak di domain pengiriman paket, Starbucks di domain kopi, sedangkan Amazon bisa punya beberapa domain (ritel dan komputasi awan). Perusahaan juga bisa berpindah domain bisnis seiring waktu (Nokia dulu berbisnis kayu, karet, lalu telekomunikasi).

Untuk mencapai tujuan bisnisnya, sebuah perusahaan membagi pekerjaannya ke dalam subdomain yang lebih kecil. Subdomain adalah area kegiatan bisnis yang lebih terperinci, bagian dari keseluruhan domain perusahaan. Tiap subdomain saling berinteraksi agar perusahaan dapat berhasil, misalnya Starbuck tidak hanya membuat kopi (subdomain kopi), tapi juga harus mengelola lokasi gerai, pegawai, dan keuangan (subdomain pendukung) agar bisnisnya lancar.

Domain-driven design (DDD) membedakan tiga jenis subdomain berdasarkan nilai strategisnya:

Subdomain Inti (Core)

Ini adalah hal-hal yang membuat perusahaan berbeda dari kompetitor. Subdomain inti mengandung keahlian khusus atau inovasi bisnis. Contohnya, Uber mempelopori ridesharing, atau algoritma pencarian Google yang unggul. Model bisnis inti biasanya kompleks dan sulit ditiru, karena di situlah perusahaan meraih keunggulan kompetitif.

Subdomain Generik (Generic)

Ini adalah aktivitas bisnis yang semua perusahaan serupa juga lakukan, dengan cara yang sama. Karena tidak memberi keunggulan khusus, perusahaan biasanya memakai solusi siap pakai. Misalnya, hampir semua sistem perlu autentikasi pengguna, lebih murah dan aman pakai implementasi umum daripada menciptakan sendiri.

Subdomain Pendukung (Supporting)

Ini subdomain yang penting bagi operasional tetapi tidak memberi keunggulan kompetitif. Misalnya, perusahaan periklanan online perlu katalog kreatif materi iklan. Mengelola katalog ini adalah subdomain pendukung: perlu dilakukan tetapi tidak perlu inovasi khusus karena tidak menambah keuntungan unik. Subdomain pendukung biasanya relatif sederhana (biasa berupa operasi CRUD atau ETL) dan mudah di-copy oleh pesaing tanpa merusak posisi bisnis.

Secara singkat, hanya subdomain inti yang memberikan nilai bisnis khusus (keunggulan kompetitif), sementara subdomain generik dan pendukung cenderung biasa-biasa saja. Akibatnya, perusahaan sering memprioritaskan investasi pada sistem dan inovasi di subdomain inti.

Orang-orang pakar domain (domain experts) adalah kunci di sini. Mereka adalah orang yang benar-benar memahami seluk-beluk bisnis, bukan para insinyur. Mereka bisa saja berasal dari manajemen, analis keuangan, atau pengguna akhir sistem, siapa saja yang tahu bisnis paling dalam. Tugas kita sebagai pengembang adalah menyerap ilmu dari mereka. Kita tidak dapat menjadi ahli domain sepenuhnya, tetapi kita harus menggunakan bahasa dan istilah yang mereka pakai agar solusi kita sesuai dengan kebutuhan nyata.

Ilustrasi Analogi: Anggap subdomain seperti bahan penyusun bangunan. Jika arsitek rumah fokus pada desain eksterior (core), urusan listrik, pipa, dan interior adalah supporting, sementara material bangunan standar (beton, baja) dianggap generic. Semua diperlukan, tapi kita akan bersusah payah mengubah desain eksterior daripada mengganti mutu semen yang digunakan semua orang.

Pada akhirnya, keseluruhan domain bisnis menentukan apa yang ingin dicapai perusahaan, sedangkan jenis-jenis subdomain menentukan bagaimana cara mencapainya. Memahami perbedaan ini sangat penting: dengan mengidentifikasi subdomain inti/generic/pendukung, kita bisa fokus merancang sistem yang tepat untuk tiap kasus.

Referensi

Konsep-konsep di atas diuraikan oleh Khononov (2022) dalam Learning Domain-Driven Design.