# 📖 Intisari Domain-Driven Design (Domain-Driven Design Distilled)
**Penulis:** Vaughn Vernon  
**Penerjemah & Penyusun:** AI Architecture Assistant  
**Rujukan:** Addison-Wesley (Pearson Education)

---

## 📑 DAFTAR ISI
1. [Kata Pengantar](#kata-pengantar)
2. [Bab 1: DDD untuk Saya (DDD for Me)](#bab-1-ddd-untuk-saya)
3. [Bab 2: Desain Strategis dengan Bounded Context dan Ubiquitous Language](#bab-2-desain-strategis-dengan-bounded-context-dan-ubiquitous-language)
4. [Bab 3: Desain Strategis dengan Subdomain](#bab-3-desain-strategis-dengan-subdomain)
5. [Bab 4: Desain Strategis dengan Pemetaan Konteks (Context Mapping)](#bab-4-desain-strategis-dengan-pemetaan-konteks-context-mapping)
6. [Bab 5: Desain Taktis dengan Agregat (Aggregates)](#bab-5-desain-taktis-dengan-agregat-aggregates)
7. [Bab 6: Desain Taktis dengan Domain Events](#bab-6-desain-taktis-dengan-domain-events)
8. [Bab 7: Alat Akselerasi dan Manajemen Proyek DDD](#bab-7-alat-akselerasi-dan-manajemen-proyek-ddd)

---

## 🌟 Kata Pengantar

Membangun model adalah aktivitas yang menyenangkan sekaligus esensial bagi kehidupan manusia. Sejak kecil kita terbiasa membuat model mainan (seperti balok LEGO, mobil-mobilan, pesawat). Di dalam kehidupan sehari-hari, kita menggunakan model di berbagai situasi: permainan papan seperti monopoli memodelkan properti dan kepemilikan, video game memodelkan dunia fantasi, dan setumpuk kartu memodelkan kekuatan/aturan tertentu.

Mengapa pemodelan begitu penting? Setiap orang memiliki gaya belajar yang berbeda: auditori (mendengar), visual (melihat gambar/diagram), dan kinestetik/taktil (melakukan/menyentuh). Membangun model perangkat lunak mampu mengakomodasi ketiga gaya belajar tersebut secara serentak.

*Domain-Driven Design* (DDD), yang pertama kali dirumuskan secara formal oleh **Eric Evans** dalam bukunya *Domain-Driven Design: Tackling Complexity in the Heart of Software*, adalah kotak perkakas (kumpulan pola desain) untuk memodelkan perangkat lunak tingkat lanjut. Buku *Domain-Driven Design Distilled* ini hadir untuk menyederhanakan, memadatkan, dan membawa esensi DDD agar dapat dipelajari dengan cepat oleh pengembang, arsitek perangkat lunak, maupun pakar domain bisnis.

---

## 🚀 Bab 1: DDD untuk Saya

### 1. Mengapa Kita Membutuhkan DDD?
Kita ingin meningkatkan keahlian teknis dan memperbesar peluang sukses proyek. Kita ingin membangun perangkat lunak yang tidak hanya benar secara model bisnis, tetapi juga berkinerja tinggi pada skala besar menggunakan arsitektur modern.

DDD menyediakan dua tingkatan instrumen:
- **Alat Desain Strategis (*Strategic Design*):** Membantu organisasi membuat keputusan arsitektur dan integrasi terbaik, memisahkan model domain berdasarkan kepentingan bisnis, dan menyoroti kompetensi inti (*Core Domain*).
- **Alat Desain Taktis (*Tactical Design*):** Membantu tim merancang kode perangkat lunak yang secara presisi mencerminkan operasi unik bisnis (melalui Entitas, Value Object, Agregat, dan Domain Event).

### 2. Desain yang Baik, Buruk, dan Efektif
Banyak tim pengembang terjebak dalam apa yang disebut **"Task-Board Shuffle"** (hanya memindahkan sticky note dari *To Do* ke *In Progress* pada papan Scrum). Tim berfokus pada kecepatan menulis kode (*coding heroics*) tanpa memikirkan desain model bisnis yang mendalam.

**Gejala Buruk dalam Rekayasa Perangkat Lunak:**
1. **Perangkat Lunak Dipandang Sebagai Beban Biaya (*Cost Center*):** Bisnis memandang software sebagai gangguan operasional, bukan keunggulan strategis.
2. **Kecanduan Teknologi (*Shiny Objects*):** Pengembang terlalu fokus mengejar framework/teknologi baru daripada memahami masalah bisnis yang sebenarnya.
3. **Database-Driven Mentality:** Diskusi solusi terlalu didominasi oleh skema tabel dan kolom database, bukan oleh alur proses bisnis riil.
4. **Kesenjangan Bahasa Bisnis vs Kode:** Pengembang memberi nama fungsi dan objek sembarangan tanpa berdialog dengan pakar domain bisnis.
5. **Terjadinya *Big Ball of Mud* (Bola Lumpur Raksasa):** Logika bisnis tercampur baur ke dalam User Interface (View), Controller, dan Model Database tanpa batas yang jelas.
6. **Kueri Database Lambat & Saling Kunci (*Locking Queries*):** Ketiadaan isolasi data menyebabkan transaksi pengguna saling mengunci dan menurunkan performa sistem.

> *"Pertanyaan apakah desain itu perlu atau mahal sebenarnya keliru: desain itu tak terelakkan. Alternatif dari desain yang baik adalah desain yang buruk, bukan tanpa desain sama sekali."*  
> — Douglas Martin

---

## 🏛️ Bab 2: Desain Strategis dengan Bounded Context dan Ubiquitous Language

### 1. Bounded Context (Batas Konteks)
*Bounded Context* adalah batasan kontekstual semantik. Di dalam batasan ini, setiap komponen dari model perangkat lunak memiliki arti spesifik dan melakukan tugas yang jelas.

- **Ruang Masalah (*Problem Space*):** Analisis strategis tingkat tinggi mengenai tujuan bisnis, risiko, dan pengelompokan fungsi bisnis.
- **Ruang Solusi (*Solution Space*):** Tempat di mana solusi diimplementasikan secara konkret sebagai kode sumber (*source code*) dan artefak perangkat lunak.

### 2. Ubiquitous Language (Bahasa Terpadu yang Baku)
Di dalam sebuah Bounded Context, tim pengembang dan Pakar Domain (*Domain Experts*) wajib menggunakan satu bahasa bersama yang ketat, baku, dan konsisten (*Ubiquitous Language*).

**Pentingnya Batas Bahasa:**
Satu istilah yang sama dapat memiliki arti yang sama sekali berbeda di konteks yang berbeda.
- Contoh istilah **"Polis" (*Policy*)** pada industri asuransi:
  - Pada *Underwriting Context*: Polis berarti evaluasi risiko properti dan penetapan premi.
  - Pada *Inspections Context*: Polis berarti laporan fisik, foto kondisi gedung, dan catatan inspektur.
  - Pada *Claims Context*: Polis berarti dokumen klaim pencairan ganti rugi bencana.
- **Solusi DDD:** Jangan satukan ketiga konsep tersebut ke dalam satu kelas raksasa `Policy`! Pisahkan menjadi 3 Bounded Context berbeda, di mana masing-masing memiliki model `Policy` yang ramping dan fokus.

### 3. Arsitektur Ports and Adapters (Hexagonal Architecture)
Di dalam Bounded Context yang bersih, logika bisnis diisolasi sepenuhnya dari detail teknologi:
- **Input Adapters:** Antarmuka pengguna (UI Controller), REST API endpoint, message listener.
- **Application Services:** Orkestrasi alur kerja, otorisasi, dan manajemen transaksi database.
- **Domain Model (Inti Bisnis Bebas Teknologi):** Entitas, Agregat, dan Value Object yang tidak terikat framework atau library luar.
- **Output Adapters:** Repositori penyimpanan database (MySQL/MongoDB), pengirim event/pesan.

---

## 🧩 Bab 3: Desain Strategis dengan Subdomain

Domain bisnis organisasi yang besar dibagi menjadi beberapa **Subdomain**:

1. **Core Domain (Domain Inti):**
   - Area investasi strategis utama yang menjadi pembeda utama perusahaan dari kompetitor.
   - Harus dikerjakan oleh tim terbaik dengan penerapan DDD paling ketat.
2. **Supporting Subdomain (Subdomain Pendukung):**
   - Fungsionalitas pendukung bisnis yang bersifat kustom karena tidak ada software jadi di pasar, tetapi bukan merupakan pembeda kompetitif utama.
3. **Generic Subdomain (Subdomain Generik):**
   - Fitur komoditas yang standar (misal: sistem penagihan tagihan dasar, modul autentikasi/login). Dapat menggunakan solusi pihak ketiga atau library siap pakai.

---

## 🗺️ Bab 4: Desain Strategis dengan Pemetaan Konteks (Context Mapping)

Context Mapping mendefinisikan hubungan kerja antar-tim dan integrasi teknis antara dua Bounded Context yang berbeda:

1. **Partnership (Kemitraan):** Dua tim bekerja sama erat; keberhasilan dan kegagalan ditanggung bersama.
2. **Shared Kernel (Inti Bersama):** Dua konteks berbagi sebagian kecil model data/kode yang sama (membutuhkan koordinasi tinggi).
3. **Customer-Supplier:** Konteks penyedia data (*Supplier / Upstream [U]*) melayani kebutuhan konteks pemakai (*Customer / Downstream [D]*).
4. **Conformist (Konformis):** Downstream terpaksa mengikuti 100% skema Upstream tanpa kemampuan mengubahnya (misal integrasi ke Amazon API).
5. **Anticorruption Layer / ACL (Lapisan Antikorupsi):**
   - Pola pertahanan terbaik ketika sistem baru harus berintegrasi dengan sistem legacy (*Big Ball of Mud*).
   - ACL bertindak sebagai penerjemah yang mengubah struktur data legacy kotor menjadi model domain baru yang bersih, sehingga model baru tidak tercemar.
6. **Open Host Service (OHS) & Published Language (PL):** Layanan API publik yang terdokumentasi rapi (misal JSON Schema / RESTful) untuk dikonsumsi banyak sistem lain.
7. **Separate Ways (Jalan Sendiri):** Memutuskan untuk tidak berintegrasi karena biaya integrasi lebih mahal daripada membuat solusi lokal kecil sendiri.

---

## 📦 Bab 5: Desain Taktis dengan Agregat (Aggregates)

Agregat adalah sekumpulan Entitas dan Value Object yang membentuk **Batasan Konsistensi Transaksional (*Transactional Consistency Boundary*)**.

### 🌟 4 Aturan Emas Desain Agregat (Vaughn Vernon):
1. **Lindungi *Business Invariants* di Dalam Batas Agregat:**
   - Semua aturan konsistensi bisnis wajib divalidasi dan dijamin benar sebelum transaksi disimpan ke database.
2. **Rancang Agregat Berukuran Kecil (*Design Small Aggregates*):**
   - Hindari membuat agregat raksasa (misal: `Product` yang menampung ribuan `BacklogItem`, `Release`, dan `Sprint`).
   - Pecah menjadi agregat-agregat kecil yang independen agar cepat dimuat, hemat memori, dan tidak memicu konflik kunci transaksi (*locking collision*).
3. **Referensi Agregat Lain Hanya Melalui Identitas (Identity Only):**
   - Agregat lain dihubungkan menggunakan ID (misal `$productId`), bukan menyimpan referensi objek memori secara langsung.
4. **Perbarui Agregat Lain Menggunakan *Eventual Consistency*:**
   - Dalam 1 transaksi database, ubah hanya **satu instans Agregat**. Jika ada agregat lain yang harus ikut berubah, perbarui melalui *Domain Events*.

---

## ⚡ Bab 6: Desain Taktis dengan Domain Events

### 1. Definisi Domain Event
*Domain Event* adalah catatan eksplisit mengenai kejadian penting yang telah terjadi di masa lalu di dalam domain bisnis.
- **Konvensi Penamaan:** Menggunakan kata kerja lampau (*Past Tense*), contoh:
  - `ProductCreated`
  - `StockReserved`
  - `InvoiceSettled`
  - `ItemPriceChanged`

### 2. Event Sourcing
Pola di mana status akhir dari suatu entitas tidak disimpan sebagai snapshot baris tabel yang di-overwrite, melainkan direkonstruksi secara berurutan dari aliran seluruh event (*event stream*) yang pernah terjadi sejak awal. Memberikan audit trail 100% akurat dan *immutable*.

---

## 🛠️ Bab 7: Alat Akselerasi dan Manajemen Proyek DDD

### 1. Event Storming
Teknik visual dan interaktif cepat yang mempertemukan Pakar Bisnis (*Domain Experts*) dan Pengembang (*Developers*) di satu ruangan:
- **Sticky Notes Oranye:** Domain Events (kejadian bisnis lampau).
- **Sticky Notes Biru Muda:** Commands (perintah/aksi pemicu event).
- **Sticky Notes Kuning:** Aggregates / Entitas (pemilik data).
- **Sticky Notes Lilac/Ungu:** Kebijakan / Proses bisnis otomatis.
- **Sticky Notes Merah/Pink:** Masalah, hambatan, atau area risiko (*Hotspots*).

### 2. Menghindari Modeling Debt
Dalam siklus rilis Agile/Scrum, tim harus realistis dalam menetapkan batasan pemodelan (*timeboxed modeling*). Perubahan pemahaman bisnis harus terus dicatat dan disempurnakan pada iterasi berikutnya.

---

### 📝 Glosarium Istilah DDD Penting

| Istilah Bahasa Inggris | Terjemahan / Definisi Bahasa Indonesia |
|---|---|
| **Bounded Context** | Batas Konteks; zona eksplisit di mana suatu model dan istilah bisnis berlaku pasti. |
| **Ubiquitous Language** | Bahasa Terpadu Baku yang disepakati bersama antara pakar bisnis dan programmer. |
| **Aggregate Root** | Entitas Induk yang menjadi gerbang utama akses dan pengontrol mutasi seluruh elemen di dalam Agregat. |
| **Value Object** | Objek Nilai yang tidak memiliki identitas unik, bersifat *immutable*, dan diidentifikasi dari seluruh atribut nilainya. |
| **Anticorruption Layer (ACL)** | Lapisan penerjemah pelindung model baru dari pencemaran struktur data sistem legacy. |
| **Domain Event** | Peristiwa bisnis signifikan di masa lalu yang dipublikasikan ke komponen lain. |
| **Anemic Domain Model** | Model domain tanpa logika bisnis (hanya getter/setter) yang merupakan anti-pattern dalam OOP murni. |