Jak definujete hranice služeb pomocí DDD bounded contexts?

Question

Accepted Answer

Dobré hranice služeb se řídí **obchodními schopnostmi**, nikoli technickými vrstvami. **Domain-Driven Design (DDD)** poskytuje přesný nástroj: **bounded context** — hranice, v níž je doménový model a jeho terminologie konzistentní.

## Bounded context

Slovo "Customer" může znamenat různé věci v různých kontextech. Každý bounded context vlastní svůj model a microservice se obvykle mapuje na jeden kontext.

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

## Jak najít hranice

- **Zarovnejte obchodní schopnosti** (Orders, Billing, Shipping), nikoli podstatná jména nebo tabulky DB.
- **Vysoká soudržnost uvnitř, volná vazba přes** hranici.
- Pozorujte, kde se mění **ubiquitous language** — to je obvykle okraj kontextu.
- K dokumentaci vztahů (upstream/downstream) použijte **context map**.

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

Pokud se dvě služby neustále volají, aby dokončily jednu operaci, je hranice pravděpodobně špatná.

## Proč je to důležité

Hranice rozhodnuté brzy jsou velmi drahé na později přesunutí, protože se zatvrdnou do API a databází, na kterých se spoléhají jiné týmy.

DDD bounded contexts vám poskytují principiální způsob, jak nakreslit tyto čáry podle obchodu, takže služby zůstávají soudržné a mohou se vyvíjet nezávisle, místo aby neustále koordinovaly.