Domain Driven Design
Le Domain Driven Design est une approche de conception logicielle formulée par Eric Evans en 2003 dans Domain-Driven Design: Tackling Complexity in the Heart of Software — le « livre bleu ». Son objet n’est ni une architecture, ni une bibliothèque de patrons : c’est une réponse à une observation simple. Dans un logiciel d’entreprise qui dure, la complexité qui coûte le plus cher n’est pas technique, elle est métier. Et le seul levier dont on dispose contre elle est un modèle — une représentation partagée du domaine, comprise autant par les développeurs que par les gens du métier, et inscrite dans le code.
D’où la thèse centrale, qui tient en une phrase : le modèle et le code sont la même chose. Un modèle qui vit dans un document Confluence n’est pas un modèle, c’est de la documentation. S’il ne se lit pas dans les noms de classes et de méthodes, il ne contraint rien et dérive dès la première semaine.
Les deux volets, et l’ordre qui compte
DDD se divise en deux ensembles de pratiques que tout oppose par l’échelle.
Le DDD stratégique traite des frontières : de quoi parle-t-on, où un mot change de sens, quelles parties du métier méritent l’effort, comment les morceaux se parlent. Il ne produit pas une ligne de code.
Le DDD tactique traite de la fabrication du modèle à l’intérieur d’une frontière : entités, objets valeur, agrégats, dépôts, événements.
Le livre d’Evans présente le tactique d’abord et le stratégique en quatrième
partie — Evans lui-même a reconnu depuis que cet ordre avait été une erreur, et
qu’il expliquait une part des échecs d’adoption. Les équipes ont retenu les
patrons — un dossier entities/, un dossier repositories/ — et sauté ce qui
donnait leur sens à ces patrons. Le stratégique se lit d’abord. Le tactique
sans lui produit du coût sans bénéfice.
Warning
Corollaire important : les patrons tactiques ne s’appliquent pas partout. Ils sont chers, et rentables uniquement dans le cœur de métier. Appliquer des agrégats et des objets valeur à un référentiel de codes postaux est une erreur de dosage, pas de la rigueur.
Le parcours
Dix pages, trois volets. Les quatre premières se lisent dans l’ordre ; les suivantes se picorent.
| Ce qu’on y répond | Page | |
|---|---|---|
| S1 | De quoi parlons-nous exactement ? | Langage omniprésent |
| S2 | Où investir l’effort de modélisation ? | Sous-domaines |
| S3 | Où s’arrête la validité d’un modèle ? | Contextes délimités |
| S4 | Comment les morceaux se parlent-ils ? | Cartographie de contextes |
| T1 | Identité ou valeur ? | Entités et objets valeur |
| T2 | Où s’arrête une transaction ? | Agrégats |
| T3 | Où va la logique qui n’appartient à personne ? | Services, dépôts et fabriques |
| T4 | Comment propager un fait sans coupler ? | Événements de domaine |
| P1 | Comment construire le modèle à plusieurs ? | Event storming |
| P2 | Comment y aller sans tout casser ? | Mise en œuvre |
DDD stratégique
- Pourquoi un glossaire ne suffit pas, ce qu’un nom mal choisi coûte réellement, et comment le vocabulaire révèle les frontières du modèle.
- Espace du problème contre espace de la solution. Cœur de métier, support, génerique — et pourquoi on n’investit pas au même endroit selon le cas.
- Le concept central : la frontière à l’intérieur de laquelle un mot a exactement un sens. Et pourquoi ce n’est pas un synonyme de microservice.
- Les neuf relations possibles entre deux contextes, amont et aval, et la couche d’anticorruption qui protège un modèle d’un voisin encombrant.
DDD tactique
- Le critère d’identité, l’immuabilité, et l’obsession des primitifs — première cause de modèles anémiques.
- La notion la plus difficile et la plus rentable. Invariants, frontière de transaction, références par identité et cohérence différée.
- Où loger la logique qui n’appartient à aucune entité, et la différence entre service de domaine et service applicatif.
- Rendre explicite ce qui s’est produit, distinguer événement de domaine et événement d’intégration, et le patron outbox.
Pratique
- L’atelier d’Alberto Brandolini : la pratique DDD au meilleur rapport valeur/effort, applicable dès la semaine prochaine.
- L’architecture qui va avec, le modèle anémique et les autres pièges, le chemin d’adoption dans un code existant — et quand s’abstenir.
Quatre malentendus à évacuer d’emblée
« DDD, c’est une architecture en couches avec des entités et des dépôts. » Non.
DDD est indifférent à l’architecture ; il exige seulement que le domaine ne dépende
de rien, ce que
l’architecture hexagonale
fournit commodément. Un dossier entities/ n’est pas du DDD.
« Un contexte délimité, c’est un microservice. » Non. Un contexte délimité peut être un module dans un monolithe — et c’est même le point de départ recommandé. La distribution est une décision de déploiement, indépendante de la décision de modélisation.
« DDD, c’est pour les gros projets. » Le critère n’est pas la taille mais la complexité métier. Une application de cent mille lignes qui déplace des données n’en a pas besoin ; un moteur de tarification de trois mille lignes peut en avoir désespérément besoin.
« On peut faire du DDD sans les gens du métier. » Non, et c’est rédhibitoire. Sans accès régulier à quelqu’un qui connaît le domaine et peut arbitrer, il ne reste que les patrons — c’est-à-dire le coût sans le bénéfice. C’est le seul prérequis véritablement bloquant.
Références
- Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003 — le livre bleu
- https://www.domainlanguage.com/ddd/reference/ — le DDD Reference d’Evans, résumé libre et gratuit de tous les patrons
- Vaughn Vernon, Implementing Domain-Driven Design, 2013 — le livre rouge, orienté mise en pratique
- Vlad Khononov, Learning Domain-Driven Design, O’Reilly, 2021 — la meilleure entrée en matière aujourd’hui
- Scott Millett & Nick Tune, Patterns, Principles, and Practices of Domain-Driven Design, 2015
- https://github.com/ddd-crew — canevas et outils d’atelier réutilisables
- https://virtualddd.com/ — communauté et sessions enregistrées