# 📖 BUKU LENGKAP: DOMAIN-DRIVEN DESIGN DISTILLED (EDISI BAHASA INDONESIA)
**Penulis Asli:** Vaughn Vernon  
**Penerbit Rujukan:** Addison-Wesley (Pearson Education)  
**Penyusun Terjemahan:** Everest ERP Architecture Team  

---

## 📑 DAFTAR ISI LENGKAP
- [Kata Pengantar (Preface)](#00-kata-pengantar-preface)
- [Bab 1: DDD untuk Saya (DDD for Me)](#01-bab-1-ddd-untuk-saya-ddd-for-me)
- [Bab 2: Desain Strategis dengan Bounded Contexts dan Ubiquitous Language](#02-bab-2-desain-strategis-dengan-bounded-contexts-dan-ubiquitous-language)
- [Bab 3: Desain Strategis dengan Subdomain](#03-bab-3-desain-strategis-dengan-subdomain)
- [Bab 4: Desain Strategis dengan Pemetaan Konteks (Context Mapping)](#04-bab-4-desain-strategis-dengan-pemetaan-konteks-context-mapping)
- [Bab 5: Desain Taktis dengan Agregat (Aggregates)](#05-bab-5-desain-taktis-dengan-agregat-aggregates)
- [Bab 6: Desain Taktis dengan Domain Events](#06-bab-6-desain-taktis-dengan-domain-events)
- [Bab 7: Alat Akselerasi dan Manajemen Proyek DDD](#07-bab-7-alat-akselerasi-dan-manajemen-proyek-ddd)
- [Bagian 8: Kode Snippet, Referensi, dan Glosarium Istilah Baku DDD](#08-kode-snippet-referensi-dan-glosarium-lengkap-ddd)

---

# 00: KATA PENGANTAR (PREFACE)

Mengapa membangun model adalah aktivitas yang begitu menyenangkan dan bermanfaat? Sejak kecil saya sangat suka membangun model mobil-mobilan dan pesawat terbang. Pada masa itu saya tidak yakin di mana LEGO berada, namun LEGO telah menjadi bagian besar dari kehidupan putra saya sejak ia masih sangat muda. Sungguh sangat memikat membayangkan dan membangun model dengan balok-balok kecil tersebut. Sangat mudah untuk menghasilkan model-model dasar, dan tampaknya Anda dapat memperluas ide-ide Anda hampir tanpa batas.

Model muncul di begitu banyak situasi dalam kehidupan. Jika Anda menikmati bermain permainan papan (*board games*), Anda sebenarnya sedang menggunakan model. Itu bisa berupa model kepemilikan lahan estat dan properti (seperti Monopoli), atau model pulau dan orang yang bertahan hidup, atau model wilayah kekuasaan dan kegiatan pembangunan. Demikian pula, video game adalah model. Kita menggunakan model sepanjang waktu dan sering kali kita tidak memberikan pengakuan yang layak bagi sebagian besar model tersebut. Model adalah bagian alami dari kehidupan kita.

Setiap orang memiliki gaya belajar masing-masing: auditori (mendengar), visual (melihat gambar/diagram), dan taktil/kinestetik (menyentuh dan melakukan secara fisik). Pembelajar auditori belajar melalui mendengar dan menyimak. Pembelajar visual belajar dengan membaca atau melihat gambaran visual. Pembelajar taktil belajar dengan melakukan sesuatu yang melibatkan sentuhan langsung. Dengan membangun model, Anda membuka peluang untuk mengakomodasi gaya belajar sebagian besar orang.

Dengan kecenderungan alami kita untuk belajar melalui pembangunan model, mengapa kita tidak secara alami berkeinginan memodelkan perangkat lunak yang semakin hari semakin membantu dan memengaruhi kehidupan kita? Faktanya, memodelkan perangkat lunak adalah hal yang sangat manusiawi.

Keinginan kuat saya adalah membantu Anda menjadi se-manusiawi mungkin dengan memodelkan perangkat lunak menggunakan beberapa alat pemodelan perangkat lunak terbaik yang ada. Alat-alat ini dikemas di bawah nama **"Domain-Driven Design"** atau **DDD**. Kotak perkakas ini pertama kali dikodifikasikan oleh **Eric Evans** dalam buku legendaris *Domain-Driven Design: Tackling Complexity in the Heart of Software*. Melalui buku ini, saya bertekad untuk membuat proses belajar dan penerapan DDD menjadi sesederhana dan semudah mungkin serta membawanya ke khalayak seluas-luasnya.

---

# 01: BAB 1: DDD UNTUK SAYA (DDD FOR ME)

Anda ingin meningkatkan keahlian Anda dan memperbesar keberhasilan proyek-proyek Anda. Anda bersemangat membantu bisnis Anda bersaing di tingkat tertinggi menggunakan perangkat lunak yang Anda ciptakan. Anda ingin mengimplementasikan perangkat lunak yang tidak hanya memodelkan kebutuhan bisnis Anda secara benar, tetapi juga mampu berkinerja pada skala besar menggunakan arsitektur perangkat lunak paling mutakhir. Mempelajari *Domain-Driven Design* (DDD) dapat membantu Anda mencapai semua itu.

### Desain yang Baik, Buruk, dan Efektif
Banyak tim pengembangan perangkat lunak bahkan tidak memikirkan desain sedikit pun. Sebaliknya, mereka melakukan apa yang saya sebut **"the task-board shuffle"** (hanya menggeser sticky note dari *To Do* ke *In Progress* di papan Scrum). Mengambil item backlog dan melakukan pergeseran tugas dianggap sebagai keseluruhan wawasan, dan sisanya diserahkan pada aksi heroik menulis kode (*coding heroics*) saat programmer memberondong kode sumber.

**10 Masalah Berbahaya dalam Rekayasa Perangkat Lunak:**
1. **Software Dianggap Cost Center:** Diperlakukan sebagai beban biaya daripada keunggulan strategis bisnis.
2. **Kecanduan Teknologi (Shiny Objects):** Developer terlalu sibuk mengejar tren teknologi baru alih-alih memahami masalah bisnis nyata.
3. **Basis Data Terlalu Mendominasi (Database-Centric):** Solusi dipikirkan dari sudut pandang tabel dan kolom relasional, bukan alur proses bisnis.
4. **Kesenjangan Bahasa:** Penamaan kelas dan fungsi kode berbeda jauh dengan istilah yang dipahami pemilik bisnis.
5. **Kurangnya Kolaborasi:** Dokumen spesifikasi tebal dibuat terisolasi dan jarang dibaca oleh programmer.
6. **Lahirnya Big Ball of Mud:** Monolit kusut tanpa batasan modul yang jelas.
7. **Logika Bisnis Tercecer:** Logika ditempatkan sembarangan di View UI, Controller, dan Helper.
8. **Kueri Database Saling Mengunci:** Memicu kelambatan dan kegagalan transaksi pengguna.
9. **Abstraksi Berlebihan:** Membuat generalisasi rumit untuk masa depan yang belum tentu terjadi.
10. **Layanan Terikat Kuat (Tightly Coupled):** Panggilan sinkron langsung antar-service memicu kegagalan berantai.

> *"Pertanyaan mengenai apakah desain itu perlu atau terjangkau sebenarnya sama sekali tidak relevan: desain itu tak terelakkan. Alternatif dari desain yang baik adalah desain yang buruk, bukan tanpa desain sama sekali."*  
> — **Douglas Martin**, *Book Design: A Practical Introduction*

---

# 02: BAB 2: DESAIN STRATEGIS DENGAN BOUNDED CONTEXTS DAN UBIQUITOUS LANGUAGE

**Bounded Context** adalah **batasan kontekstual semantik**. Di dalam batasan tersebut, setiap komponen dari model perangkat lunak memiliki arti yang spesifik dan melakukan tugas-tugas yang spesifik.

### Ruang Masalah (Problem Space) vs Ruang Solusi (Solution Space)
- **Problem Space:** Tempat analisis strategis tingkat tinggi mengenai pendorong bisnis, risiko, dan pengelompokan fungsi.
- **Solution Space:** Tempat implementasi nyata solusi sebagai basis kode sumber (*source code*) dan artefak pengujian yang terpisah.

### Analogi Batas Bahasa: Contoh Polis Asuransi (Policy)
Istilah yang sama persis dapat memiliki arti yang sama sekali berbeda di konteks divisi bisnis yang berbeda:
- **Underwriting Context:** Polis berarti evaluasi risiko properti dan penetapan tarif premi asuransi.
- **Inspections Context:** Polis berarti kondisi fisik bangunan di lapangan, foto kerusakan, dan catatan inspektur.
- **Claims Context:** Polis berarti dokumen pelacakan klaim ganti rugi dan persetujuan pencairan dana nasabah.

DDD melarang keras menggabungkan ketiga makna polis tersebut ke dalam satu kelas monolitik raksasa `Policy`. Sebaliknya, buatlah 3 Bounded Context terpisah yang masing-masing memiliki kelas `Policy` yang ramping, bersih, dan fokus.

### Studi Kasus: Pemurnian Model Agile Project Management
Dalam memodelkan aplikasi Scrum, konsep inti adalah `Product`, `BacklogItem`, `Release`, dan `Sprint`. Godaan tim untuk memasukkan konsep seperti `Tenant`, `User`, `Permission`, `Payment`, `SupportPlan`, dan `Forum` ke dalam model Scrum harus ditolak. Konsep-konsep tersebut harus dikeluarkan ke Bounded Context pendukung terpisah agar Core Domain tetap murni dan tidak menjelma menjadi *Big Ball of Mud*.

### Pengujian Eksekutabel BDD (Given / When / Then)
```gherkin
Scenario: Product Owner melakukan commit backlog item ke sprint
  Given sebuah backlog item yang telah dijadwalkan untuk rilis
  And Product Owner dari backlog item tersebut
  And sebuah sprint untuk komitmen
  And kuorum persetujuan tim untuk komitmen
  When Product Owner melakukan commit backlog item ke sprint
  Then backlog item berhasil di-commit ke sprint
  And event BacklogItemCommitted berhasil diterbitkan
```

---

# 03: BAB 3: DESAIN STRATEGIS DENGAN SUBDOMAIN

Organisasi membagi keseluruhan domain bisnisnya ke dalam tiga jenis Subdomain:

| Jenis Subdomain | Karakteristik & Nilai Bisnis | Strategi Rekayasa DDD |
|---|---|---|
| **Core Domain** | Pembeda kompetitif utama perusahaan di pasar. Area di mana bisnis wajib unggul secara mutlak. | Pusatkan investasi pengembang terbaik, terapkan DDD murni dengan perlindungan konsistensi tertinggi. |
| **Supporting Subdomain** | Model pendukung yang dibangun kustom karena software siap pakai tidak tersedia di pasar. | Penting untuk kesuksesan Core Domain, namun dibangun secara sederhana tanpa investasi berlebih. |
| **Generic Subdomain** | Fitur komoditas standar (misal autentikasi login, pengiriman email, gateway pembayaran bank). | Gunakan software jadi (SaaS), library pihak ketiga, atau outsourcing. |

---

# 04: BAB 4: DESAIN STRATEGIS DENGAN PEMETAAN KONTEKS (CONTEXT MAPPING)

Context Mapping mendefinisikan hubungan kerja dan integrasi teknis antar Bounded Context:
- **Partnership:** Dua tim berkomitmen untuk sukses bersama atau gagal bersama.
- **Shared Kernel:** Membagi sebagian kecil model data dan basis kode bersama.
- **Customer-Supplier:** Upstream (penyedia layanan) melayani kebutuhan Downstream (pelanggan).
- **Conformist:** Downstream terpaksa menyesuaikan diri 100% dengan skema Upstream tanpa kemampuan negosiasi.
- **Anticorruption Layer (ACL):** Lapisan isolasi pelindung untuk menerjemahkan data kotor sistem legacy (*Big Ball of Mud*) menjadi model baru yang bersih.
- **Open Host Service (OHS) & Published Language (PL):** Protokol antarmuka publik standar terbuka (seperti RESTful JSON) yang terdokumentasi rapi.
- **Asynchronous Messaging:** Integrasi paling tangguh di mana event dipublikasikan secara asinkron tanpa memblokir proses pemanggil, didukung oleh pola *At-Least-Once Delivery* dan *Idempotent Receiver*.

---

# 05: BAB 5: DESAIN TAKTIS DENGAN AGREGAT (AGGREGATES)

Agregat adalah sekumpulan Entitas dan Value Object yang membentuk **batasan konsistensi transaksional atomik**.

### 🌟 4 Aturan Emas Desain Agregat:
1. **Lindungi Business Invariants di Dalam Batas Agregat:** Semua aturan bisnis wajib divalidasi dan dijamin konsisten sebelum transaksi disimpan ke basis data.
2. **Rancang Agregat Berukuran Kecil (Design Small Aggregates):** Pecah model raksasa menjadi agregat-agregat kecil yang independen (misal: memecah `Product` menjadi `Product`, `BacklogItem`, `Release`, dan `Sprint`) agar cepat dimuat, hemat memori, dan bebas konflik kunci transaksi.
3. **Referensi Agregat Lain HANYA Melalui Identitas (ID Only):** Hubungkan agregat lain hanya dengan menyimpan ID-nya (Value Object), bukan menyimpan referensi pointer objek memori langsung.
4. **Perbarui Agregat Lain Melalui Eventual Consistency:** Dalam 1 transaksi basis data, modifikasi hanya 1 instans Agregat. Perubahan ke agregat lain disinkronkan secara bertahap melalui Domain Events.

---

# 06: BAB 6: DESAIN TAKTIS DENGAN DOMAIN EVENTS

**Domain Event** adalah catatan resmi mengenai kejadian penting di masa lalu di dalam domain bisnis. Dinamai menggunakan kata kerja bentuk lampau (*Past Tense*): `ProductCreated`, `OrderInvoiced`, `StockHeld`.

### Event Sourcing
Status akhir suatu objek tidak disimpan sebagai satu baris tabel yang ditimpa, melainkan direkonstruksi dari aliran kronologis seluruh peristiwa (*event stream*) yang pernah terjadi sejak awal. Pola ini memberikan performa penyimpanan *append-only* yang sangat cepat, jejak audit 100% *immutable*, dan kemampuan *time-travel debugging*.

---

# 07: BAB 7: ALAT AKSELERASI DAN MANAJEMEN PROYEK DDD

### Event Storming
Metode desain cepat dan interaktif yang mempertemukan Pakar Bisnis dan Pengembang di depan dinding kertas panjang menggunakan catatan tempel (*sticky notes*):
- 🟧 **Oranye:** Domain Events (kejadian masa lampau).
- 🟦 **Biru Muda:** Commands (perintah pemicu aksi).
- 🟨 **Kuning:** Aggregates / Entitas (pemilik data dan logika bisnis).
- 🟪 **Lilac:** Proses otomatis / Kebijakan alur kerja.
- 🟩 **Hijau:** Tampilan antarmuka pengguna (View).
- 🟥 **Merah / Hotspot:** Area risiko, hambatan, atau ketidaksepakatan bisnis.

### Estimasi Usaha Berbasis Metrik
| Tipe Komponen | Mudah (Jam) | Sedang (Jam) | Rumit (Jam) |
|---|:---:|:---:|:---:|
| **Domain Event** | 0.1 | 0.2 | 0.3 |
| **Command** | 0.1 | 0.2 | 0.3 |
| **Aggregate** | 1.0 | 2.0 | 4.0 |
| **UI View / Adapter** | 0.5 | 1.5 | 3.0 |

---

# 08: KODE SNIPPET, REFERENSI, DAN GLOSARIUM LENGKAP DDD

```csharp
/*
Contoh Pengujian Penerimaan Unit Test Komitmen Backlog Item ke Sprint
*/
[Test]
public void ShouldCommitBacklogItemToSprint()
{
    // Given
    var backlogItem = BacklogItemScheduledForRelease();
    var productOwner = ProductOwnerOf(backlogItem);
    var sprint = SprintForCommitment();
    var quorum = QuorumOfTeamApproval(backlogItem, sprint);

    // When
    backlogItem.CommitTo(sprint, productOwner, quorum);

    // Then
    Assert.IsTrue(backlogItem.IsCommitted());
    var backlogItemCommitted = backlogItem.Events.OfType<BacklogItemCommitted>().SingleOrDefault();
    Assert.IsNotNull(backlogItemCommitted);
}
```

### Glosarium Baku Istilah DDD
- **Bounded Context:** Batas semantik eksplisit di mana model domain dan istilah bisnis berlaku pasti.
- **Ubiquitous Language:** Bahasa baku terpadu yang dipahami dan dipakai bersama oleh pakar bisnis dan programmer di dalam kode.
- **Aggregate Root:** Entitas induk pengendali akses dan integritas seluruh data di dalam batasan Agregat.
- **Value Object:** Objek yang tidak memiliki identitas unik dan bersifat kekal (*immutable*).
- **Anticorruption Layer (ACL):** Lapisan pelindung penerjemah data untuk mencegah pencemaran model baru dari sistem legacy.
- **Anemic Domain Model:** Anti-pattern di mana model hanya berisi properti dan getter/setter tanpa perilaku bisnis.
- **Event Sourcing:** Rekonstruksi status akhir objek dari aliran seluruh kejadian masa lalunya.