Lors de DDD Europe 2020, avec Anthony, grâce à la technique du Pac-Man, nous avons pu échanger avec de nombreux professionnels intéressés par le DDD (puisque participants à la conférence) et nous avons posé en substance la même question à toutes ces personnes : "Quelle est la maturité d'utilisation du DDD que vous observez ?".

Cela va sans dire mais c'est toujours mieux en le disant : cet article ne reflète que les échanges que nous avons eus et nos avis ! Il ne s'agit absolument pas d'un état objectif du DDD !

Les réponses

Sans grande surprise, toutes les personnes avec qui nous avons pu échanger considéraient que le DDD était très loin d'être adopté ou connu. De leurs observations, la très grande majorité des applications sont basées sur des modèles anémiques et cela quelque soit le pays. Nous avons parlé avec des Français mais aussi des Belges, des Allemands, des Suisses, des Anglais, des Américains, des Italiens, des Portugais et bien sur des Néerlandais puisque la conférence était à Amsterdam : tout le monde partage ce constat !

Plus étonnant par contre au vu du lieu : les Speakers mis à part, la très grande majorité des personnes ne considéraient pas "faire du DDD" (quoique cela puisse vouloir dire). Si beaucoup étaient là pour découvrir, et dans une volonté d'adopter l'approche, certains considéraient aussi mal faire du DDD :

• Parfois par manque d'implication des experts métier ;
• Souvent à cause d'un mauvais découpage qui avait entraîné la création d'un monolithe distribué plutôt que de microservices !

Pour les personnes voulant adopter le DDD,  elles considéraient trop souvent le DDD comme une approche de design sur tableau blanc. De fait, les représentants de ces entreprises étaient trop souvent des personnes ne faisant pas de code au quotidien : Architectes d'entreprise ou Product Owners.

Notre réaction

Voyant que beaucoup de personnes imaginaient utiliser le DDD comme un simple outil d'analyse et de modélisation, notre discours à été systématiquement le même : nous avons parlé de nos convictions personnelles pour l'adoption du DDD !

Dans l'état actuel de notre compréhension et de réflexion, il n'est absolument pas pertinent de faire du DDD (là encore quoique cela puisse vouloir dire) sans maîtriser le Test Driven Development.

Le premier constat menant à cette réflexion est qu'il est primordial d'impliquer le développement dans la modélisation : "Hands-on Modelers" ! En se contentant de faire des analyses "hors code" on ne pourra pas capturer toutes les subtilités du Domain car seul le code demande de résoudre tous les détails. En réalité, la seule vraie représentation du Domain c'est le code, pas ce qui est sur le tableau !

Un autre constat menant à cette réflexion est que la capacité à faire du Refactoring (et plus précisément du Refactoring Toward Deeper Insight) est essentielle au DDD. On ne peut pas modéliser correctement notre Domain du premier coup. Certains implicites vont devenir explicites en avançant sur le projet. De fait, dès qu'une nouvelle compréhension apparaît, il est nécessaire de faire un Refactoring dans le code pour refléter cette nouvelle compréhension (et faire apparaître les nouvelles notions).

Un développeur travaillant en TDD fera une bonne centaine de Refactorings par jour aussi ce type d'opération est un non événement. Une pratique saine du TDD nous permet de changer parfois en profondeur une solution en étant guidé et avec un filet de sécurité assurant la non régression à chaque changement.

A l'inverse, s'il n'y a pas de pratique du TDD, sans cette habitude du Refactoring et sans filet de sécurité, les Refactorings nécessaires pour faire apparaître cette nouvelle compréhension ne seront tout simplement pas totalement faits. Plusieurs raisons à cela :

• Sans habitude des pratiques, faire un Refactoring prend beaucoup de temps et d'énergie : deux ressources très limitées dans les journées d'un développeur ;
• Sans filet de sécurité, on n'osera pas faire de Refactorings "violents", on ne fera que de toutes petites opérations de peur de casser un traitement.

Un autre point essentiel, pour nous, à la pratique du TDD comme pré-requis au DDD est en fait la puissance de design offerte par le TDD (oui, le TDD est une pratique de design par les tests, pas uniquement une pratique de tests). Aujourd'hui, nous n'avons pas expérimenté de meilleure technique que le TDD pour designer nos solutions !

Lorsque maîtrisé, le TDD permet de faire des designs élégants, pertinents et pragmatiques dans un temps extrêmement réduit ! Les solutions produites de cette manière répondront correctement aux problèmes posés sans chercher à répondre à des problèmes qui n'existent en fait pas (et qui n'existeront probablement jamais). Ce type de design est exactement celui que l'on cherche à produire avec le DDD, les deux approches sont complémentaires et doivent être utilisées conjointement !

Enfin, un dernier point qui, pour nous, justifie d'apprendre le TDD avant le DDD est l'utilisation d'une Clean Architecture (nous utilisons essentiellement Ports and Adapters). Lorsque l'on veut faire du TDD, il est naturel de faire apparaître cette Separation Of Concerns pour pouvoir tester chaque élément de notre solution d'une manière adaptée.

Ce type d'architectures étant essentiel pour la protection du Domain Model, et donc au DDD, nous considérons qu'il est très pertinent d'apprendre leurs utilisations et leur utilités par le TDD.

Malheureusement, apprendre le TDD demande du temps et de l'énergie donc nous avons humblement conseillé à nos différents interlocuteurs de commencer par le TDD avant de se lancer dans le développement d'un Domain Model.

Est-ce qu'on a bien fait ?

Les conversations que nous avons eues n'était absolument pas préparées et nos avis ont bien été présentés comme tels ! Nous n'avons absolument pas affirmé que c'était LA voie à suivre (ce qui aurait été stupide lors d'une conférence avec des speakers tels que Eric Evans, Kent Beck ou Alberto Brandolini).

Cependant, ces différents échanges ont permis la formalisation d'une réflexion qui était jusque-là une conviction personnelle que nous partagions sans vraiment le savoir.

Nous espérons avoir pu apporter une vision différente à certains participants mais, ce qui est certain, c'est que l'importance du TDD pour la pratique du DDD est maintenant bien plus claire pour nous !