Bagaimanakah anda mentakrifkan sempadan perkhidmatan menggunakan bounded context DDD?

Question

Accepted Answer

Sempadan perkhidmatan yang baik mengikut **keupayaan perniagaan**, bukan lapisan teknikal. **Domain-Driven Design (DDD)** memberi alat yang tepat untuk ini: **bounded context** — sempadan di mana model domain dan istilahnya konsisten.

## Bounded context

Perkataan "Customer" boleh membawa maksud berbeza dalam konteks berbeza. Setiap bounded context memiliki modelnya sendiri, dan sebuah microservice lazimnya dipetakan kepada satu konteks.

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

## Bagaimana mencari sempadan

- **Selaraskan dengan keupayaan perniagaan** (Orders, Billing, Shipping), bukan kata nama atau jadual DB.
- **Kohesi tinggi di dalam, loose coupling merentas** sempadan.
- Perhatikan di mana **ubiquitous language** berubah — itu biasanya tepi konteks.
- Gunakan **context map** untuk mendokumentasikan hubungan (upstream/downstream).

## Anti-pattern

```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 perkhidmatan sentiasa memanggil satu sama lain untuk menyelesaikan satu operasi, sempadan itu mungkin salah.

## Mengapa ia penting

Sempadan yang diputuskan awal sangat mahal untuk dialihkan kemudian, kerana ia mengeras menjadi API dan pangkalan data yang bergantung kepada pasukan lain.

Bounded context DDD memberi anda cara berprinsip untuk melukis garisan tersebut mengikut perniagaan, supaya perkhidmatan kekal kohesif dan boleh berkembang secara bebas dan bukannya sentiasa menyelaras.