# BAB 7: ALAT AKSELERASI DAN MANAJEMEN PROYEK DDD
**Buku:** Domain-Driven Design Distilled  
**Penulis:** Vaughn Vernon  
**Penerjemah:** Everest ERP Architecture Team  

---

Ketika menggunakan DDD, kita berada dalam pencarian pembelajaran mendalam tentang bagaimana bisnis bekerja, dan kemudian memodelkan perangkat lunak berdasarkan luasnya pembelajaran kita. Ini benar-benar proses belajar, bereksperimen, menantang asumsi, belajar lebih banyak lagi, dan memodelkan kembali. Kita perlu memproses dan menyaring pengetahuan (*knowledge crunching*) dalam jumlah besar serta menghasilkan desain yang efektif dalam memenuhi kebutuhan strategis organisasi.

Tantangannya adalah: **kita harus belajar dengan cepat**. Dalam industri yang serba cepat, kita sering kali berkejaran dengan waktu. Waktu sangat berarti, dan waktu umumnya mendorong banyak keputusan kita. Jika kita tidak menyerahkan perangkat lunak tepat waktu dan sesuai anggaran, apa pun yang telah kita capai dengan perangkat lunak tersebut, kita tampak seperti telah gagal. Semua orang mengandalkan kita untuk sukses dalam segala hal.

Sayangnya, satu respons umum terhadap tekanan negatif ini adalah mencoba menghemat dan memperpendek jadwal dengan **meniadakan desain**. Ingat kembali dari bab pertama bahwa **desain itu tak terelakkan**: Anda akan gagal sebagai akibat dari desain yang buruk, atau Anda akan sukses dengan menghadirkan desain yang efektif. Jadi, apa yang harus Anda lakukan adalah menjawab tuntutan waktu tersebut secara langsung dan melakukan desain dengan cara yang diakselerasi (*accelerated design*), menggunakan pendekatan yang akan membantu Anda menghadirkan desain terbaik dalam batas waktu yang Anda miliki.

---

### Event Storming: Teknik Desain Cepat dan Visual

**Event Storming** adalah teknik desain cepat yang dirancang untuk melibatkan Pakar Domain (*Domain Experts*) dan Pengembang (*Developers*) dalam proses pembelajaran yang serba cepat. Teknik ini berfokus pada **proses bisnis dan alur kerja nyata**, bukan pada tabel database atau diagram kelas yang kaku.

Saya pertama kali belajar tentang Event Storming bertahun-tahun yang lalu dari **Alberto Brandolini**. Pada suatu kesempatan, karena kekurangan waktu, Alberto memutuskan bahwa ia harus membuang UML dan menggunakan catatan tempel (*sticky notes*) warna-warni sebagai gantinya. Ini adalah kelahiran pendekatan pembelajaran cepat dan desain perangkat lunak yang membuat semua orang di ruangan terlibat secara langsung dalam proses tersebut.

#### Keunggulan Utama Event Storming:
1. **Sangat Taktil & Partisipatif:** Setiap orang memegang pulpen dan bantalan sticky note. Pakar bisnis dan programmer berdiri sejajar untuk berkontribusi pada *Ubiquitous Language*.
2. **Berfokus pada Kejadian Bisnis (*Events*):** Menyingkirkan kode dan perdebatan teknis dari eksperimen awal.
3. **Sangat Cepat dan Sangat Murah:** Anda dapat memodelkan seluruh *Core Domain* baru dalam hitungan beberapa jam saja. Jika sebuah konsep salah, Anda cukup meremas sticky note tersebut dan membuangnya ke tempat sampah tanpa beban biaya.
4. **Memicu Terobosan Pemahaman (*Breakthroughs*):** Menyamakan persepsi dan mengungkap kesalahpahaman bisnis sejak hari pertama sebelum ada sebaris kode pun yang ditulis.

---

### Perlengkapan dan Warna Baku Sticky Notes dalam Event Storming

Untuk mengadakan sesi Event Storming, siapkan dinding yang luas (panjang minimal 10 meter) yang dilapisi kertas gulung putih, spidol hitam berujung runcing untuk setiap orang, dan sticky notes dengan kode warna standar:

```
+------------------+-------------------------------------------------------+
| WARNA STICKY NOTE| ARTI / KOMPONEN DOMAIN                                |
+------------------+-------------------------------------------------------+
| 🟧 Oranye        | DOMAIN EVENT (Kejadian bisnis masa lampau)            |
| 🟦 Biru Muda     | COMMAND (Perintah aksi pemicu event)                  |
| 🟨 Kuning        | AGGREGATE / ENTITAS (Pemilik data dan aturan bisnis)  |
| 🟪 Lilac / Ungu  | PROCESS / POLICY (Proses otomatis / alur lanjutan)    |
| 🟩 Hijau         | VIEW / PROJECTION (Tampilan layar yang dilihat user)  |
| 🟨 Kuning Cerah  | USER ROLE (Peran pengguna yang memicu aksi)          |
| 🌸 Pink          | BOUNDED CONTEXT (Nama batasan konteks)                |
| 🟥 Merah / Ungu  | HOTSPOT / RISK (Masalah, ambiguitas, atau bottleneck) |
+------------------+-------------------------------------------------------+
```

---

### 5 Langkah Praktis Menjalankan Event Storming:

#### Langkah 1: Badai Domain Events (Oranye)
- Tempelkan sticky note **oranye** di sepanjang dinding kertas dari **kiri ke kanan berdasarkan urutan waktu (*timeline order*)**.
- Tulis setiap event menggunakan **kata kerja bentuk lampau** (contoh: `ProductCreated`, `InvoiceIssued`, `StockAllocated`).
- Jika ada event yang terjadi secara paralel, posisikan secara vertikal (atas-bawah).
- Jika ada area yang membingungkan atau diperdebatkan, tandai segera dengan sticky note **merah/hotspot**.

#### Langkah 2: Buat Commands Pemicu (Biru Muda)
- Tulis **Command** pemicu dalam kalimat imperatif (contoh: `CreateProduct`, `IssueInvoice`).
- Pasangkan sticky note biru muda tepat di sebelah kiri Domain Event oranye yang dihasilkannya.
- Tempelkan stiker kecil kuning di sudut kiri bawah jika ada peran khusus (*User Role*, misal `Product Owner`, `Kasir`).

#### Langkah 3: Asosiasikan Agregat / Entitas (Kuning)
- Tuliskan nama kata benda Agregat yang bertanggung jawab mengeksekusi Command dan menerbitkan Event (contoh: `Product`, `Invoice`).
- Tempatkan sticky note kuning sedikit di atas pasangan Command/Event tersebut.

#### Langkah 4: Gambar Batasan Bounded Contexts & Aliran Event
- Gunakan spidol hitam untuk menggambar garis batas:
  - **Garis Solid:** Batas *Bounded Context*.
  - **Garis Putus-putus:** Batas *Subdomain*.
- Tempelkan sticky note **pink** untuk memberi nama masing-masing *Bounded Context*.
- Gambar garis panah untuk menunjukkan arah aliran *Domain Events* yang melintasi satu konteks ke konteks lainnya.

#### Langkah 5: Identifikasi Tampilan Pengguna (Hijau)
- Identifikasi layar/antarmuka penting (*View*) yang dibutuhkan user untuk melakukan aksinya menggunakan sticky note **hijau**.

---

### Mengelola DDD pada Proyek Agile Scrum

#### 1. Merekrut Orang yang Tepat (*First Things First*)
Tidak ada pengganti untuk pengembang yang kompeten dan bermotivasi tinggi. DDD adalah filosofi tingkat lanjut yang membutuhkan pengembang di atas rata-rata yang bersedia mendengarkan bisnis dan memahami bahasa domain secara mendalam.

#### 2. Analisis SWOT (Strengths, Weaknesses, Opportunities, Threats)
Gunakan matriks 4 kuadran di papan Scrum untuk memetakan:
- **Strengths (Kekuatan):** Keunggulan model yang sudah solid.
- **Weaknesses (Kelemahan):** Area model yang masih ambigu atau rapuh.
- **Opportunities (Peluang):** Fitur domain baru yang dapat membuka pasar baru.
- **Threats (Ancaman):** Risiko teknis atau ketergantungan pada sistem legacy yang buruk.

#### 3. Mengelola Modeling Debt (Hutang Pemodelan)
Dalam timebox sprint, Anda tidak akan selalu sempat menyempurnakan model hingga sempurna. Akui adanya **Hutang Pemodelan (*Modeling Debt*)**, catat di sesi retrospektif, dan jadwalkan perbaikannya pada sprint berikutnya.

---

### Estimasi Usaha Berbasis Metrik (*Metrics-Based Estimation*)

Gunakan tabel estimasi berbasis komponen hasil Event Storming untuk menghindari tebak-tebakan jam kerja:

| Tipe Komponen Arsitektur | Mudah (*Easy*) | Sedang (*Moderate*) | Rumit (*Complex*) |
|---|:---:|:---:|:---:|
| **Domain Event** | 0.1 jam | 0.2 jam | 0.3 jam |
| **Command** | 0.1 jam | 0.2 jam | 0.3 jam |
| **Aggregate** | 1.0 jam | 2.0 jam | 4.0 jam |
| **View / UI Adapter** | 0.5 jam | 1.5 jam | 3.0 jam |
| **Event Serializer / Repository** | 0.5 jam | 1.0 jam | 2.0 jam |

Tambahkan seluruh unit estimasi untuk semua komponen yang ada di sprint berjalan untuk mendapatkan total estimasi yang ilmiah dan akurat hingga tingkat akurasi di bawah 20%.

---

### Panduan Berinteraksi Efektif dengan Pakar Domain (*Domain Experts*)

Pakar Domain memiliki jadwal yang padat. Buat waktu pertemuan menjadi sangat berharga dan menyenangkan:
1. **Sesi Event Storming Terbatas:** Maksimal 2–3 jam per sesi (jangan lakukan seharian penuh agar pikiran tetap segar).
2. **Iterasi Skenario Cepat:** Batasi diskusi pemurnian 1 skenario bisnis dalam waktu 10–20 menit.
3. **Review Pengujian Otomatis:** Ajak Pakar Domain membaca pengujian penerimaan (BDD / Unit Test). Pengujian yang ditulis dengan *Ubiquitous Language* yang baik memungkinkan Pakar Domain memverifikasi kebenaran logika bisnis dalam waktu 1–2 menit per test!