Wie definieren Sie Servicegrenzen mit DDD Bounded Contexts?

Question

Accepted Answer

Gute Servicegrenzen folgen **geschäftlichen Fähigkeiten**, nicht technischen Schichten. **Domain-Driven Design (DDD)** bietet ein präzises Werkzeug: das **Bounded Context** — eine Grenze, innerhalb derer ein Domänenmodell und seine Begriffe konsistent sind.

## Bounded Context

Das Wort "Customer" kann in verschiedenen Kontexten verschiedene Bedeutungen haben. Jedes Bounded Context besitzt sein eigenes Modell, und ein Microservice bildet sich normalerweise auf einen Kontext ab.

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

## Wie man Grenzen findet

- **Auf geschäftliche Fähigkeiten ausrichten** (Orders, Billing, Shipping), nicht auf Nomen oder Datenbanktabellen.
- **Hohe Kohäsion innen, lockere Kopplung über** die Grenze.
- Beobachten Sie, wo sich die **Ubiquitous Language** ändert — das ist normalerweise eine Kontextgrenze.
- Verwenden Sie eine **Context Map**, um Beziehungen (Upstream/Downstream) zu dokumentieren.

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

Wenn zwei Services sich ständig gegenseitig aufrufen, um eine Operation abzuschließen, ist die Grenze wahrscheinlich falsch.

## Warum es wichtig ist

Grenzen, die früh festgelegt werden, sind sehr teuer, um sie später zu verschieben, weil sie sich in APIs und Datenbanken verhärten, auf die andere Teams angewiesen sind.

DDD Bounded Contexts geben dir eine systematische Möglichkeit, diese Linien entlang des Geschäfts zu ziehen, damit Services zusammenhängend bleiben und sich unabhängig weiterentwickeln können, anstatt ständig zu koordinieren.