Hvordan definerer du servicegraenser ved hjælp af DDD bounded contexts?

Question

Accepted Answer

Gode servicegraenser følger **forretningskapaciteter**, ikke tekniske lag. **Domain-Driven Design (DDD)** giver et præcist værktøj til dette: **bounded context** — en grænse, inden for hvilken en domænemodeleller og dens vilkår er konsistente.

## Bounded context

Ordet "Customer" kan betyder forskellige ting i forskellige sammenhænge. Hver bounded context ejer sin egen model, og en microservice kortlægger typisk til én kontekst.

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

## Sådan finder du graenser

- **Justere til forretningskapaciteter** (Orders, Billing, Shipping), ikke substantiver eller databasetabeller.
- **Høj sammenhæng inden for, løs kobling på tværs af** grænsen.
- Iagttag, hvor det **ubiquitous language** ændrer sig — det er normalt en kontekstgrænse.
- Brug et **context map** til at dokumentere forhold (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
```

Hvis to tjenester konstant kalder hinanden for at fuldføre en operation, er grænsen sandsynligvis forkert.

## Hvorfor det betyder noget

Graenser, der bestemmes tidligt, er meget dyre at flytte senere, fordi de hærdner til API'er og databaser, som andre teams afhænger af.

DDD bounded contexts giver dig en principiel måde at tegne disse linjer langs virksomheden på, så tjenester forbliver kohærent og kan udvikle sig uafhængigt i stedet for konstant at koordinere.