Tour d'horizon : Domain Driven Design

écrit par Jeremy Genard publié le mardi 25 février 2020
Un terme de plus en plus présent sur les Internets lorsqu'il s'agit d'architecture et de conception, le Domain Driven Design ou Conception Pilotée par le Domaine pour les allergiques de Shakespeare, est une méthode développée par Eric Evans depuis près de 20 ans.

Dans cet article, je vous propose un ensemble de liens vous permettant d'explorer le DDD en posant les bases de la méthode, en vous aidant à décider si c'est fait pour vous ou non, en mettant en avant des aides pour déployer le DDD dans votre projet du côté métier ainsi que du côté technique.

Le Domain Driven Design, c'est quoi ?

Le premier élément de réponse est l'incontournable livre fondateur d'Eric Evans, le père du DDD, il n'existe pas de version gratuite mais il se trouve facilement sur Amazon ou d'autres boutiques :

Si le livre vous parait trop indigeste, InfoQ a écrit un résumé conséquent disponible gratuitement au format PDF (il est payant au format papier) :

Enfin, si vous préférez les images, Scott Millett et Samuel Knight font un grand tour d'horizon avec une infographie de qualité, également gratuite au format PDF :

Ok mais DDD, c'est pour moi ou pas ?

Le second grand évangéliste du DDD, Vaughn Vernon, a mis au point une grille d'évaluation pour déterminer si c'est intéressant de le mettre en place sur votre projet :

Le blog Tech Beacon met en avant d'autres raisons pour basculer sur DDD, attention toutefois, leur avis semble très orienté. Il faut donc prendre un peu de recul sur ce qui est dit :

Maintenant, comment je le vend à mon client ?

Barry O'Sullivan est un développeur qui fait beaucoup d'ateliers et de conférences autour du DDD et de l'Event Storming. Très actif dans la communauté Irlandaise, il propose un REX au travers de son blog et d'une présentation :

Super ! Tout le monde est convaincu, mais le métier est perdu.

Pas de problème, il existe plusieurs procédés pour inclure le métier facilement et de manière ludique dans cette nouvelle organisation. Attention ! Les ateliers suivants ne sont pas exclusifs au DDD mais ils aident grandement à la conception du domaine.

Scenario Mapping

Un atelier pour mettre les utilisateurs en avant dans le processus de conception en décrivant les scénarios utilisateurs.

Event Storming

Avec des post-it et un petit groupe hétérogène, on décrit un système de manière itérative. Les événements, les actions, les acteurs et ainsi de suite jusqu'à ce que la fonctionnalité soit complètement définie.

Context Mapping

Cette fois, on place les éléments extérieurs au logiciel au centre de l'atelier. Ici, on va se baser sur les idées, les émotions, les peurs de nos utilisateurs pour fiabiliser nos fonctionnalités et valider l'expérience utilisateur.

J'ai tout ce qu'il faut pour démarrer, un budget, des spécifications. Pour l'architecture, ça se passe comment ?

Je vous reparle de Vaughn Vernon parce qu'il a écrit le pendant pratique du livre d'Eric Evans dont je fais la promotion en début d'article, c'est un incontournable pour avoir l'exhaustivité technique sur le sujet :

Projet d'exemple extrêmement bien documenté avec une série d'articles. Parfait pour s'approprier le principe de DDD !

Microsoft a mis en ligne une très bonne documentation autour de DDD dans une architecture micro-services.

J'ai tout compris, mon projet est un succès et j'aimerais aller plus loin !

Pour conclure ce tour d'horizon du DDD, je vous propose deux pistes supplémentaires pour creuser encore un peu plus le sujet. Je vous invite également à partager votre avis, vos liens et vos retours d'expérience sur le DDD en commentaires de cet article.

Sandro Mancuso, un pilier de la communauté Software Craftsmanship, s'est grandement inspiré du DDD pour son Interaction Driven Design :

CQRS et Event Sourcing sont deux briques techniques qui reviennent systématiquement lorsqu'on évoque DDD. Martin Fowler en parlera mieux que moi :