DDD (Domain-Driven Design)

Approche de conception logicielle qui structure le code autour du domaine métier, en s'appuyant sur un langage partagé et des contextes délimités.

En clair

Le Domain-Driven Design est une approche de conception qui place le métier au centre. Plutôt que d'organiser le code selon des considérations techniques, on le structure selon les concepts et les règles du domaine. Le DDD propose un vocabulaire : le « langage omniprésent » (un vocabulaire commun entre experts métier et développeurs), les « contextes délimités » (des frontières où un terme a un sens précis et stable), ainsi que des briques tactiques comme les entités, les objets-valeurs et les agrégats. Un même mot, comme « client », peut d'ailleurs recouvrir des réalités différentes selon le contexte (la facturation, le support, le marketing) : le DDD assume cette pluralité plutôt que de chercher un modèle unique forcément flou. L'agrégat, lui, regroupe des objets qui doivent rester cohérents ensemble et fixe la frontière à l'intérieur de laquelle les règles métier s'appliquent.

Pourquoi c'est utilisé

Aligner le code sur le métier réduit les malentendus et limite les zones où la complexité s'accumule sans raison. Les contextes délimités donnent des frontières claires, ce qui facilite la maintenance et prépare d'éventuels découpages en services. Le langage partagé fluidifie les échanges entre les équipes techniques et les métiers, et fait du code une traduction fidèle des règles réelles. Quand le code emploie exactement les mots des experts, une conversation sur une règle métier se traduit presque directement en modification de code, sans couche de traduction approximative. Les frontières de contexte limitent aussi la propagation des changements : modifier la facturation n'oblige pas à toucher au support.

En mission / dans la pratique

Le consultant mobilise le DDD lors d'ateliers de modélisation, en clarifiant le vocabulaire avec les experts métier et en définissant les frontières des contextes. Au quotidien, cela se traduit par une organisation du code par domaine, des noms qui reflètent le métier, et une vigilance sur les agrégats et leurs règles de cohérence. C'est autant une discipline de communication qu'une technique de code. Des ateliers collaboratifs, comme l'event storming, aident à faire émerger les événements métier, les commandes et les frontières naturelles avant d'écrire la moindre ligne. La cartographie des relations entre contextes (qui dépend de qui, qui impose son modèle à qui) est souvent aussi précieuse que le code des agrégats eux-mêmes.

Pièges & bonnes pratiques

Le DDD n'est pas justifié partout : sur un domaine simple, il ajoute une complexité inutile. Réservez-le aux domaines à forte richesse métier. Évitez le « DDD de surface » qui ne reprend que le jargon sans le modèle. Investissez d'abord dans le langage omniprésent et les frontières de contexte avant les patterns tactiques. Ne cherchez pas non plus à modéliser tout le système d'un coup : commencez par le cœur de métier qui apporte le plus de valeur, et traitez les parties génériques ou secondaires de façon plus simple. Gardez enfin le modèle vivant : il doit évoluer au fil de la compréhension du métier, pas être figé après le premier atelier.

À ne pas confondre

Le DDD guide souvent le découpage en microservices ou en modules d'un monolithe, mais reste avant tout une méthode de conception. Il se combine bien avec CQRS et avec une architecture événementielle pour exprimer les changements de domaine.

ForTeam IT à vos côtés

Vous recherchez une mission ou un consultant expert sur ce sujet ? ForTeam IT met en relation des consultants IT freelance sélectionnés avec des grands comptes, ETI et scale-ups partout en France. Consultez aussi notre grille des TJM freelance IT et nos expertises par technologie.

Rejoindre la communauté