Piye carane ngedefinisikake layanan boundaries nggunakake DDD bounded contexts?

Question

Accepted Answer

Layanan boundaries sing apik ngetutake **kemampuan bisnis**, dudu lapisan teknis. **Domain-Driven Design (DDD)** menehi alat sing presisi kanggo iki: **bounded context** — wates ing mana domain model lan tembung-tembunge konsisten.

## Bounded context

Tembung "Customer" bisa nduwe makna beda-beda ing konteks beda-beda. Saben bounded context duwe modelne dhewe, lan microservice biasane memetakan menyang siji konteks.

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

## Piye carane nemokake boundaries

- **Selaras karo kemampuan bisnis** (Orders, Billing, Shipping), dudu kata benda utawa tabel DB.
- **Kohesi dhuwur ing jero, kopeling kendor ing pinggir** boundary.
- Payu ing ngendi **ubiquitous language** owah — kuwi biasane pinggir konteks.
- Gunakake **context map** kanggo dokumentasi relasi (upstream/downstream).

## Anti-patterns

```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
```

Yen rong layanan terus-terusan nggunem layanan liyane kanggo ngrampungake siji operasi, boundary bisa jadi salah.

## Ora perlu digoleki

Boundaries sing diputusake awal larang banget kanggo dipindhah mengko, amarga bisa ngeras dadi API lan database sing layanan liyane ngandelake.

DDD bounded contexts menehi carane prinsip kanggo nggawe garis kasebut miturut bisnis, mula layanan tetep kohesif lan bisa berkembang mandiri tinimbang terus-terusan koordinasi.