Le DDD n'est pas une architecture, c'est une façon de penser la conception logicielle à partir du métier. Une approche qui évite des années de dette technique en posant les bonnes fondations.
Le Domain-Driven Design, conceptualisé par Eric Evans dans son célèbre « Blue Book » de 2003, part d'un constat simple : les logiciels les plus difficiles à maintenir sont ceux dont le code ne ressemble pas au métier qu'il modélise. Quand les développeurs et les experts métier ne parlent pas le même langage, des malentendus s'accumulent couche après couche jusqu'à rendre le système impénétrable.
Le concept de Ubiquitous Language est la première étape. Il s'agit de créer un vocabulaire partagé entre les équipes tech et métier, qui se reflète directement dans le code : les noms de classes, de méthodes, de variables. Une Commande en Java doit désigner la même chose qu'une commande dans le cerveau du responsable commercial. Un Bounded Context délimite ensuite les zones où ce vocabulaire est valide — le concept de « Client » n'a pas les mêmes attributs dans le contexte de la facturation et dans celui du support client.
En pratique, DDD s'applique surtout aux domaines complexes à forte logique métier. Pour un CRUD simple, c'est du sur-engineering. Mais pour des systèmes de tarification complexes, des workflows multi-étapes ou des règles métier changeantes, investir dans une modélisation DDD en amont économise des mois de refactoring ultérieur.
→ À lire aussi : Architecture hexagonale · Microservices vs Monolithe