Bagaimana Anda mendefinisikan batas layanan menggunakan konteks terikat DDD?

Question

Accepted Answer

Batas layanan yang baik mengikuti **kemampuan bisnis**, bukan lapisan teknis. **Domain-Driven Design (DDD)** memberikan alat yang tepat untuk ini: **konteks terikat** — batas dalam mana model domain dan istilahnya konsisten.

## Konteks terikat

Kata "Customer" dapat berarti hal yang berbeda dalam konteks yang berbeda. Setiap konteks terikat memiliki modelnya sendiri, dan mikroservis biasanya memetakan ke satu konteks.

```text
┌───────────────────┐   ┌────────────────────┐
│  Sales context    │   │  Support context   │
│  Customer =       │   │  Customer =        │
│   leads, orders   │   │   tickets, SLAs    │
└───────────────────┘   └────────────────────┘
   one service             another service
```

## Cara menemukan batas

- **Selaraskan dengan kemampuan bisnis** (Pesanan, Penagihan, Pengiriman), bukan nama atau tabel DB.
- **Kohesi tinggi di dalam, cengkeraman longgar di seluruh** batas.
- Perhatikan tempat **bahasa ubiquitous** berubah — itu biasanya tepi konteks.
- Gunakan **peta konteks** untuk mendokumentasikan hubungan (upstream/downstream).

## Pola anti

```text
✗ Entity services ("User service", "Product service") — too fine, chatty
✗ Splitting by technical layer (a "database service")
✗ Boundaries that force a distributed transaction for every operation
```

Jika dua layanan terus-menerus memanggil satu sama lain untuk menyelesaikan satu operasi, batas mungkin salah.

## Mengapa ini penting

Batas yang diputuskan lebih awal sangat mahal untuk dipindahkan nanti, karena mereka mengeras menjadi API dan database yang bergantung pada tim lain.

Konteks terikat DDD memberi Anda cara yang terbukti untuk menarik garis-garis tersebut di sepanjang bisnis, sehingga layanan tetap kohesif dan dapat berkembang secara independen daripada terus-menerus berkoordinasi.