Jak definiujesz granice usług za pomocą DDD bounded contexts?

Question

Accepted Answer

Dobre granice usług podążają za **możliwościami biznesowymi**, a nie za warstwami technologicznymi. **Domain-Driven Design (DDD)** dostarcza precyzyjne narzędzie do tego: **bounded context** — granicę, w obrębie której model domeny i jego terminy są spójne.

## Bounded context

Słowo "Customer" może oznaczać różne rzeczy w różnych kontekstach. Każdy bounded context ma własny model, a microusługa zazwyczaj mapuje się na jeden kontekst.

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

## Jak znaleźć granice

- **Wyrównaj się do możliwości biznesowych** (Orders, Billing, Shipping), a nie rzeczowników lub tabel bazy danych.
- **Wysoka spójność wewnątrz, słabe sprzężenie między** granicami.
- Zwróć uwagę, gdzie zmienia się **ubiquitous language** — to zwykle krawędź kontekstu.
- Użyj **context map** do dokumentowania relacji (upstream/downstream).

## Anti-wzorce

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

Jeśli dwie usługi ciągle wzywają się nawzajem, aby ukończyć jedną operację, granica jest prawdopodobnie błędna.

## Dlaczego to ważne

Granice ustalone wcześnie są bardzo kosztowne do przeniesienia później, ponieważ ulegają ossifikacji w interfejsach API i bazach danych, na których polegają inne zespoły.

DDD bounded contexts dają ci zasadniczy sposób narysowania tych linii wzdłuż biznesu, aby usługi pozostały spójne i mogły się rozwijać niezależnie zamiast stale się koordynować.