Hur definierar du tjänstgränser med DDD bounded contexts?

Question

Accepted Answer

Bra tjänstgränser följer **affärsfunktioner**, inte tekniska lager. **Domain-Driven Design (DDD)** ger ett exakt verktyg för detta: **bounded context** — en gräns inom vilken en domänmodell och dess termer är konsistenta.

## Bounded context

Ordet "Kund" kan betyda olika saker i olika sammanhang. Varje bounded context äger sin egen modell, och en mikrotjänst mappar vanligtvis till en kontext.

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

## Hur du hittar gränser

- **Anpassa till affärsfunktioner** (Beställningar, Fakturering, Leverans), inte substantiv eller databastabeller.
- **Högt samanhang inuti, löst samband över** gränsen.
- Titta på var det **gemensamma språket** ändras — det är vanligtvis en kontextkant.
- Använd en **context map** för att dokumentera relationer (upstream/downstream).

## Anti-mönster

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

Om två tjänster ständigt anropar varandra för att slutföra en operation är gränsen förmodligen fel.

## Varför det spelar roll

Gränser som bestäms tidigt är mycket dyra att flytta senare, eftersom de härdar till API:er och databaser som andra team förlitar sig på.

DDD bounded contexts ger dig ett principierat sätt att dra dessa linjer längs verksamheten, så tjänster förblir sammanhängande och kan utvecklas oberoende istället för att ständigt samordna sig.