Domain-Driven Design : de la stratégie aux contextes délimités
Le Domain-Driven Design (DDD) n'est ni un framework ni une bibliothèque. C'est un ensemble de principes pour structurer le logiciel autour des domaines métier. En 2026, le DDD reste la méthodologie la plus fiable pour décomposer des systèmes complexes, en particulier pour définir les frontières de microservices.
Taxonomie des concepts DDD
Domain-Driven Design
├── Conception Stratégique
│ ├── Contexte Délimité (Bounded Context)
│ ├── Langage Ubiquitaire
│ ├── Cartographie des Contextes
│ ├── Sous-domaines (Cœur / Support / Générique)
│ └── Vision du Domaine
├── Conception Tactique
│ ├── Entités
│ ├── Objets Valeur
│ ├── Agrégats (+ Racine d'Agrégat)
│ ├── Ãvénements de Domaine
│ ├── Repositories
│ ├── Fabriques
│ └── Services de Domaine
└── Patterns d'Intégration
├── Couche Anti-Corruption (ACL)
├── Noyau Partagé
├── Service Hôte Ouvert
├── Langage Publié
└── Client-Fournisseur
Patterns Stratégiques vs Tactiques
| Aspect | Patterns Stratégiques | Patterns Tactiques |
|---|---|---|
| Portée | Système entier, inter-équipes | Au sein d'un contexte délimité |
| Parties prenantes | Architectes, PMs, experts métier | Développeurs, tech leads |
| Livrable | Cartes de contexte, frontières d'équipe | Structure du code, modèle de domaine |
| Application | Avant de construire | Pendant l'implémentation |
| Risque si omis | Mauvaises frontières, retravail coûteux | Modèle anémique, fuites de logique |
| Effort | Ateliers, sessions EventStorming | Refactoring continu |
| Réversibilité | Faible (impact organisationnel) | Moyenne (changements de code) |
Checklist d'identification des contextes délimités
| # | Question | Signal |
|---|---|---|
| 1 | Ce domaine a-t-il son propre vocabulaire ? | Termes différents = contexte différent |
| 2 | Une équipe différente le gérerait-elle ? | L'alignement organisationnel compte |
| 3 | A-t-il un cycle de vie distinct ? | Déploiement indépendant = contexte séparé |
| 4 | Les règles de cohérence different-elles ? | Cohérence forte vs éventuelle |
| 5 | Y a-t-il une frontière de transaction naturelle ? | Les frontières d'agrégat indiquent les contextes |
| 6 | Modifier ceci casserait-il des fonctionnalités non liées ? | Signal de couplage |
| 7 | Ce sous-domaine offre-t-il un avantage concurrentiel ? | Coeur vs support vs générique |
| 8 | Les patterns de lecture/écriture different-ils ? | Candidat CQRS au sein du contexte |
Pièges courants
Obsession des entités -- Les équipes modélisent tout en Entité alors que les Objets Valeur sont plus simples et plus sûrs. Si deux objets avec les mêmes attributs sont interchangeables, utilisez un Objet Valeur.
Ignorer la conception stratégique -- Sauter directement aux Agrégats sans cartographier les contextes mène au monolithe distribué. La conception stratégique n'est pas optionnelle.
Un modèle pour les gouverner tous -- Un "Client" en facturation n'est pas le même qu'un "Client" en expédition. Laissez chaque contexte posséder son propre modèle.