Ma petite définition du DDD

Contexte d’écriture du présent article : je termine tout juste une formation sur DDD et une façon de l’implémenter avec CQRS/ES, mes connaissances sont donc fraiches. C’est la raison pour laquelle je veux tenter une explication qui sera probablement naïve mais qui je l’espère, sera plus compréhensible pour des gens découvrant seulement la notion.

DDD est un acronyme pour Domain Driven Design ou Conception Pilotée par le Métier.

Il s’agit d’un ensemble de pratiques ayant pour but une meilleure gestion de la complexité dans le cadre du développement d’un logiciel. Par gestion, j'entends séparation de la complexité essentielle(celle du métier) des complexités obligatoire(celle liée aux nécessités techniques d'implémentation) et accidentelle (celle liée aux errements de conception/développement).

Certaines des pratiques du DDD sont orientées vers la technique, on parle alors de patterns tactiques. En parallèle s'ajoutent les patterns stratégiques qui vont permettre de s’attaquer à l’analyse, la modélisation et la compréhension du métier. Certains patterns tactiques sont connus hors du DDD :  microservices, CQRS/ES, repository,… Mais il faut garder à l’esprit que l’essence du DDD se trouve dans les patterns stratégiques et que si la technique et les implémentations peuvent évoluer très vite, l’approche du métier reste elle, pour l’instant, relativement atemporelle.

Côté stratégique :

Parler le même langage que le métier et faire en sorte que ce langage, toute sa terminologie, soit utilisée de manière non équivoque à tous les niveaux de l'équipe: métier, PO, développeurs... Chaque terme employé doit l'être en connaissance de cause et ne porter aucun sous-entendu. Si un doute sur la portée d'un terme subsiste, il est crucial de le lever et de s'accorder sur les non-dits inhérents à la polysémie de chaque mot.

C’est le contexte d’application dudit langage commun. Quand le responsable marketing de Justin Bridou vous annonce qu’il s’est payé une caravane, demandez-lui s’il part en vacances ou s’il est bien placé pour le tour de France !

Côté tactique :

Isoler le code métier :

L’implémentation de la logique métier est cruciale pour le business de votre client ! Ne la polluez pas avec des accès base de données ou de la sérialisation json ! Gardez ça pour l’extérieur, faite de l’inversion de dépendance !

Protéger les code métier :

Aucune référence extérieure! Si vous avez besoin de données venues de l'extérieur, transformez-les pour qu'elles s'insèrent dans votre métier! Ne tordez pas le cou à votre modélisation pour satisfaire des contraintes extérieures. On parle ici de couches d'anticorruption ou "anticorruption layer".

Voila en résumé les premiers concepts qui m’ont permis de comprendre ce qui se racontait en meet-up et en coding dojo! Certains préfèreront certainement en mettre d’autres en avant, mais ce sont vraiment ceux qui m’ont permis de mettre le pied à l’étrier!