Technique & développement
Domain Driven Design (DDD)
Approche de conception qui place le métier au centre du logiciel, en modélisant fidèlement le domaine et son vocabulaire avec les experts métier.
Qu'est-ce que le Domain Driven Design (DDD) ?
Le Domain Driven Design (DDD, ou « conception pilotée par le domaine ») est une approche de développement logiciel qui place le métier au cœur de la conception. Plutôt que de partir de la technique, on commence par modéliser fidèlement le domaine — le secteur d'activité, ses règles, son vocabulaire — et le code en devient le reflet le plus exact possible.
Formalisée par Eric Evans en 2003, l'idée est simple mais exigeante : un logiciel est d'autant plus juste qu'il parle le langage de ceux qui l'utilisent. Si vos experts métier parlent de « dossier », « émargement » ou « habilitation », ces mots doivent se retrouver tels quels dans le code, sans traduction approximative.
Les principes clés du DDD
Le DDD repose sur quelques notions structurantes :
- Le langage commun (ubiquitous language) : un vocabulaire partagé entre développeurs et experts métier, utilisé partout — réunions, documentation, code. Fini les malentendus entre « ce que le client a dit » et « ce que le développeur a compris ».
- Les contextes délimités (bounded contexts) : on découpe le domaine en zones cohérentes, chacune avec son propre modèle. Le mot « client » peut signifier autre chose à la facturation qu'au support — et c'est très bien.
- Le modèle du domaine : des objets riches qui portent à la fois les données et les règles métier, plutôt que des structures de données passives.
À quoi sert le DDD concrètement ?
Le DDD prend toute sa valeur sur les domaines complexes, là où la difficulté n'est pas technique mais métier : assurance, santé, logistique, formation réglementée, finance. Dans ces univers, le vrai défi est de comprendre et modéliser correctement les règles, souvent subtiles et pleines d'exceptions.
| Sans DDD | Avec DDD |
|---|---|
| Le code traduit (mal) le métier | Le code reflète fidèlement le métier |
| Malentendus client / dev fréquents | Langage commun partagé |
| Règles métier éparpillées | Règles centralisées dans le modèle |
| Évolutions risquées | Évolutions alignées sur le métier |
En contrepartie, le DDD demande un investissement : du temps d'échange avec les experts, une vraie phase de modélisation. Sur un domaine simple, c'est souvent disproportionné — un logiciel de gestion basique n'en a pas besoin.
DDD, Clean Architecture et microservices
Le DDD fournit le « quoi » (un modèle métier fidèle), tandis que la Clean Architecture fournit le « comment » (les couches pour le protéger). Les deux se complètent parfaitement. Les bounded contexts du DDD servent aussi de frontières naturelles pour un éventuel découpage en microservices : chaque contexte peut devenir un service autonome, le jour où l'échelle le justifie.
DDD et sur-mesure
Le DDD est dans l'ADN du logiciel sur-mesure bien fait. Un logiciel métier n'a de valeur que s'il épouse fidèlement votre façon de travailler. Chez AppMinds, nous investissons le temps nécessaire à comprendre votre domaine — c'est souvent là que se joue la différence entre un outil qu'on subit et un outil qui fait vraiment gagner du temps. Nous adaptons la profondeur du DDD à la complexité réelle, sans dogmatisme.
Questions fréquentes
Le DDD est-il réservé aux gros projets ? Il est surtout adapté aux domaines métier complexes, quelle que soit la taille. Sur un domaine simple, sa rigueur apporte peu et coûte du temps.
DDD et méthode agile sont-ils compatibles ? Oui, très bien. Le langage commun et les modèles affinés au fil des itérations s'intègrent naturellement dans une démarche agile.
Le DDD impose-t-il une technologie particulière ? Non. C'est une approche de conception, indépendante du langage ou du framework. On l'applique aussi bien avec Laravel qu'avec n'importe quelle autre stack.
