Date de mise à jour : 29/05/2026
TL;DR : Le Domain Driven Design (DDD) est une approche de développement logiciel qui aligne le code sur le métier via un langage commun et des patterns d'implémentation éprouvés. Selon le Stack Overflow Developer Survey 2024, 63 % des ingénieurs citent la dette technique comme leur principale frustration au travail, signe que la qualité de modélisation du code reste un enjeu majeur. DDD est une réponse structurée à ce problème.
Tout part d’une conversation
Pour notre présentation nous prendrons Alice et Bob.
Bob est responsable marketing d’une société de service.
Bob cherche à améliorer la visibilité de l’entreprise auprès des talents et potentiels clients.
En regardant les sujets à la mode, le sujet Domain Driven Design sort du lot.
Alice est développeuse. Elle a déjà fait des projets en suivant les principes et les patrons de conception (souvent appelé design pattern) proposés par Eric Evans dans son ouvrage Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley, 2003, 560 pages).
Naturellement Bob va voir Alice :
(Bob): ça serait bien de faire un article sur « Domain Driven Design », les tests fonctionnels et « Qu’est-ce que le modèle MVC, à quoi sert-il ? »
(Alice): Aucun rapport entre MVC, les tests fonctionnels et DDD.
(Bob): Je ne m’y connais pas en DDD. Par contre, tu prends certains de nos concurrents, ils publient massivement sur le sujet
(Alice): c’est dommage que tu ne connaisses pas grand chose en DDD vu que tu conduis le projet de refonte du site.
(Bob): Je suis métier pas fonctionnel. Chacun son métier ?
(Alice): justement le DDD ça concerne le métier ?
(Alice): C’est parti !
Cet échange illustre le problème central que DDD cherche à résoudre : le fossé de compréhension entre métier et technique. Quand ce fossé se creuse, les projets dérivent, les coûts explosent, et la dette technique s'accumule. Une étude de Standish Group (CHAOS Report) révèle que 83,8% des projets informatiques échouent partiellement ou totalement dont 52,7%, terminés, mais hors budget, hors délai et/ou avec moins de fonctionnalités, et tout cela souvent pour des raisons d'alignement défaillant entre métier et IT.
De quoi parle le domain driven design (DDD) ? Définition
Du métier ! enfin, du domaine. Bref c’est la même chose
L’idée est assez simple : Une solution logicielle répond à un besoin métier. Donc pour construire le logiciel, il faut s’appuyer sur le métier.
Pfiou je suis fatigué
Jusque là pas de soucis. Mais on fait comment ??
C’est là que ça se complique et que Eric Evans et ses copains interviennent et boom des millions de ressources disponibles.
Essai de définition de DDD, les 3 piliers fondamentaux :
- Approche de développement logiciel centrée sur le métier (domaine) : le logiciel modélise fidèlement les règles et concepts du métier, pas l'inverse.
- Qui permet d’aligner les intervenants sur le vocabulaire et les concepts métiers : langage ubiquitaire (Ubiquitous Language)
- Et propose des patrons de conception (design pattern) pour l’implémentation de domaines métiers complexes.
En résumé : limiter l’écart entre la réalité du métier et son implémentation avec la conception pilotée par le domaine.
Quand on regarde la représentation classique d'une architecture ddd , on se rend compte que c’est pas évident :
Surtout que le livre d’Eric Evans fait 500 pages et c’est bien mieux écrit que cet article.
On va essayer de paraphraser.
Niveau stratégique : La définition du domaine
- L’application s’inscrit dans un contexte métier que l’on appelle « Core Domain » : le cœur du métier, ce qui crée la valeur différenciante de l'entreprise.
- Pour décliner « Core Domain » on découpe le métier en contextes indépendants nommés « Bounded Context » : périmètre fonctionnel autonome avec son propre modèle et vocabulaire.
- Le nommage de tous les éléments du métier et des contextes sont regroupés dans « Ubiquitous Language » : le dictionnaire partagé entre métier et technique dans un contexte donné.
- La cohérence des « Bounded Context » est garantie par la « Context Map » : la cartographie des relations entre Bounded Contexts (upstream/downstream, Anti-Corruption Layer…).
Et la définition de tout ça c’est le travail du métier ! mais pas seulement.
Dans la vraie vie, structurer un domaine (métier) c’est pas facile, surtout quand on n’a jamais fait l’exercice.
On va laisser la partie « Comment je définis mon domaine ? » à un prochain article.
niveau tactique : L’implémentation du domaine
Maintenant comment traduit-on le domaine en code durant l’implémentation ? Le design de l’application se fait en prenant le métier et en apportant une réponse technique.
Le Domain-Driven Design définit :
- Une Entity comme étant une « ressource » identifiable par un identifiant: la modification d’une Entity ne change pas son identification.
- Un Value Object comme étant une « ressource » identifiable par sa valeur: la modification d’un Value Object change son identification
- Un Domain Event comme étant l’expression d’un changement d’état.
- Un Aggregate comme étant un regroupement d’Entity et de Value Object partageant un objectif et des règles métier afin d’encapsuler leur cohésion.
La définition de ces objets se fait conjointement entre le métier et la technique.
Cas concret : modéliser le si d'une esn avec ddd
Imaginons une solution de gestion des ressources d’une ESN (version volontairement minimaliste) permettant de gérer les services recrutement, rh et commerce.
Le core domain est donc le métier de l’ESN et ses règles de gestion, ses invariants.
Dans notre exemple, on définit des bounded context calqués sur les services de l’entreprise. (il est possible de découper autrement)
Les services RH, recrutement et commerce sont donc des bounded context.
Au sein du service de recrutement on parle de candidats.
Au sein du service RH on parle de collaborateurs.
Au sein du service commerce on parle de profils.
Dans cet exemple « candidats », « collaborateurs » et « profils » concernent des personnes. Seulement en fonction du contexte le vocabulaire ainsi que le cycle de vie des entités ne sont pas les mêmes pour :
- un candidat, le recrutement va s’intéresser aux expériences passées et aux compétences.
- un collaborateur, le service RH va s’intéresser aux informations civiles et aux compétences pour suivre la formation.
- un profil, le commerce va s’intéresser aux compétences et à la disponibilité.
On pourra décliner pour :
- le bounded context recrutement un agrégat « Candidat » composé d’une entité « Expérience » et d’un value object « Compétence ».
- le bounded context RH un agrégat « Collaborateur » composé d’une entité « InformationsCiviles » et d’un value object « Compétence ».
- le bounded context recrutement un agrégat « Profil » composé d’une entité « Disponibilités » et d’un value object « Compétence ».
Note: Le terme "compétence" est défini dans les 3 bounded contexts, mais ne représente pas la même chose, ça dépend du contexte. En Recrutement, elle qualifie un candidat pour un poste. En RH, elle sert à planifier des formations. En Commerce, elle permet de proposer un profil à un client. Dans une approche Domain-Driven Design on analyserait la pertinence du nommage compétence en fonction du contexte et définirait les informations nécessaires à leur usage.
Coté événement du domaine imaginons :
- Le changement de statut marital d’un collaborateur dans le contexte RH.
- L’embauche d’un candidat dans le contexte recrutement.
- Le changement de disponibilité d’un profil dans le contexte commerce.
Pour finir nous aurons donc l’ubiquitous language suivant:
Dans le contexte RH :
un collaborateur a des informations civiles et des compétences.
un collaborateur change son statut marital
Dans le contexte recrutement :
un candidat a des expériences et des compétences.
on embauche un candidat.
Dans le contexte commerce :
un profil a des disponibilités et des compétences.
un profil change de disponibilité
L’implémentation de ce domaine se ferait de la manière la plus directe possible en faisant abstraction des contraintes techniques (on parle de layered architecture).
namespace RH {
class Collaborateur {
IEnumerable<RH.Competence> Competences { get; }
RH.InformationCivile InformationCivile { get; }
void ChangeStatutMarital(StatutMarital statutMarital) {
/* validation des règles métier + stockage de l'information */
InformationCivile.StatutMarital = statutMarital;
EmetEvenement(CollaborateurAChangeDeStatusMarital());
}
}
}
namespace Recrutement {
class Candidat {
IEnumerable<Recrutement.Competence> Competences { get; }
IEnumerable<Recrutement.Experience> Experiences { get; }
void Embauche() {
/* validation des règles métier + stockage de l'information */
EmetEvenement(CandidatEmbauche());
}
}
}
namespace Commerce {
class Profil {
IEnumerable<Commerce.Competence> Competences { get; }
Commerce.Disponibilite Disponibilite { get; }
void ChangeDisponibilite(Commerce.Disponibilite disponibilite) {
/* validation des règles métier + stockage de l'information */
Disponibilite = disponibilite;
EmetEvenement(ProfilAChangeDeDisponibilite());
}
}
}
Conclusion
Domain Driven Design est une approche qui permet au métier de mieux définir ses cas d’usages et problématiques et aux développeurs de construire une solution répondant à ces besoins.
Domain-Driven Design implique un investissement fort en temps de modélisation et de collaboration entre métier et technique, souvent sous-estimé lors du lancement de projet.
En revanche, les bénéfices sont documentés : meilleure maintenabilité du code, réduction de la dette technique, alignement durable entre IT et business. Des sociétés comme Uber, Netflix ou Zalando ont publié leurs retours d'expérience sur l'adoption de DDD dans leurs architectures microservices à grande échelle. Vous l'aurez compris de nombreuses ressources sont disponibles via votre moteur de recherche (c’est pas loin).
Voici quelques ressources pour commencer:
Retour aux articles