Comment définir les limites de service en utilisant les contextes délimités de la DDD ?

Question

Accepted Answer

Les bonnes limites de service suivent les **capacités métier**, non les couches techniques. Le **Domain-Driven Design (DDD)** fournit un outil précis pour cela : le **contexte délimité** — une limite dans laquelle un modèle de domaine et ses termes sont cohérents.

## Contexte délimité

Le mot « Customer » peut signifier différentes choses dans différents contextes. Chaque contexte délimité possède son propre modèle, et un microservice correspond généralement à un contexte.

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

## Comment trouver les limites

- **Aligner sur les capacités métier** (Commandes, Facturation, Expédition), pas sur les noms ou les tables de base de données.
- **Forte cohésion à l'intérieur, couplage faible à travers** la limite.
- Observez où le **langage omniprésent** change — c'est généralement une bordure de contexte.
- Utilisez une **context map** pour documenter les relations (amont/aval).

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

Si deux services s'appellent constamment pour compléter une opération, la limite est probablement mauvaise.

## Pourquoi c'est important

Les limites décidées tôt sont très coûteuses à déplacer plus tard, car elles se durcissent en APIs et en bases de données sur lesquelles d'autres équipes dépendent.

Les contextes délimités de la DDD vous donnent une façon principes de tracer ces lignes le long du métier, pour que les services restent cohésifs et puissent évoluer indépendamment plutôt que de constamment se coordonner.