Le DDD, pour Domain-Driven Design (ou conception pilotée par le domaine en français) est une approche qui indique que toute la conception d’une application doit être centrée sur le métier, pour des domaines présentant des problématiques complexes. Ainsi, la structure, le nom des classes, des champs, les actions des fonctions… tout dans le code doit refléter le métier, peu importe si le langage utilisé pour répondre au besoin du client est PHP, Java, Ruby ou Python. Autrement dit, il s’agit de représenter le métier directement dans le code.
Nicolas Barlogis, coach technique et craftsmanship, nous explique comment mettre en œuvre cette démarche DDD, pour amener d’un côté les développeurs à retranscrire l’intention du métier dans le code, et de l’autre le métier à faire comprendre le cœur de son activité à l’équipe technique.
Peux-tu nous expliquer en quoi consiste le Domain-Driven Design ?
Initialement le DDD est un livre d’Eric Evans, le « big blue book » intitulé : Domain-Driven-Design, Tackling Complexity in the Heart of Software, publié en 2003. C’est encore aujourd’hui une référence, malgré son « grand âge ». Dans les grandes lignes, il indique que la démarche DDD peut commencer à très haut niveau (CEO), en partant des objectifs stratégiques et globaux d’une société, pour redescendre jusqu’au niveau du code qui profitera de toute la somme de connaissance assimilée lors de la démarche. Le DDD définit ainsi des patterns stratégiques et des patterns tactiques. Les stratégiques concernent l’organisation et la méthodologie afin de savoir comment découper les applications, définir qui est responsable de quoi, etc. Les tactiques définissent comment refléter dans le code la somme de connaissance accumulée. Cela doit permettre d’éviter dans un premier temps le décalage dans les échanges et les connaissances entre les métiers et les équipes techniques. Et dans un second temps, le DDD doit isoler la logique métier de la contrainte technique : le fonctionnel dans le code doit toujours être au service du métier et non l’inverse.
Comment cela se traduit concrètement ?
Il faut avoir en tête que la matière première du développeur, c’est la connaissance ! L’enjeu pour celui-ci étant de récupérer suffisamment de connaissance métier pour la traduire dans le code. Pour ce faire, le Knowledge Crunching (ou analyse des connaissances en français) est un processus itératif et collaboratif visant à extraire et à raffiner les connaissances d’un domaine métier afin de construire un modèle logiciel pertinent et efficace. C’est un concept central dans le Domain-Driven Design, comme celui de « l’ubiquitous language ». Ce dernier vise à réduire le fossé entre les métiers et la technique en définissant un langage unique pour tout le monde (qui peut différer du langage utilisé par les métiers entre eux) et qui va permettre d’exprimer efficacement le besoin. Un ubiquitous language que l’on va même retrouver jusque dans le code !
Des patterns stratégiques vont ainsi se dessiner peu à peu avec le domaine (qui décrit les grands domaines métiers comme la vente, la logistique, le SAV…), qui vont aider à définir des « Bounded Context » (soit pour un domaine métier donné ses différentes sous composantes, avec leur ubiquitous language propre. Par exemple l’approvisionnement des dépôts et l’envoi aux clients particuliers sont deux contextes différents, appartenant au domaine de la logistique) et la façon dont ces sous-domaines interagissent entre eux grâce à la « Context Map » . C’est ce qui permettra de donner la façon dont les futures équipes devront interagir entre elles. Cette démarche va permettre une construction en couche (layered architecture) qui va définir une logique métier découplée des notions techniques. Ainsi les patterns tactiques vont permettre d’exprimer directement dans le code les connaissances acquises dans les phases précédentes, en séparant la logique fonctionnelle des contraintes techniques (les couches de logique métier étant isolés de la logique technique). Car il faut bien comprendre cette nuance : le DDD ne demande pas de coder le métier, mais de mettre le métier dans le code.
Pour en savoir plus sur notre parcours de formation dédié au Domain-Driven Design !
Est-ce difficile de mettre en œuvre cette démarche DDD ?
Une démarche DDD représente déjà un travail de longue haleine, qu’il s’agisse des patterns stratégiques mais aussi tactiques. De plus, les notions de découverte de logique métier et d’intégration dans le code sont très complexes. Heureusement, des spécialistes du DDD ont développé le « Domain-Driven Design Starter Modeling Process », qui propose une approche structurée pour débuter sa démarche DDD. Il sert ainsi de point de départ pour explorer et comprendre un domaine métier, puis à construire un modèle initial qui servira de base à l’évolution de l’applicatif. Les étapes clés sont l’exploration du domaine (identification des experts du domaine, ubiquitous language, identification des concepts clés), la modélisation initiale (diagrammes de contexte, diagrammes de domaines, diagrammes de classes) et la partie validation et itération (revue avec les experts du domaine et itérations).
Tout cela implique une forte collaboration entre les métiers et les équipes techniques, ce qui indique une mobilisation en personne et en temps. Il est donc nécessaire d’obtenir un réel soutien de la hiérarchie pour réussir une telle démarche, car elle est itérative. En effet, rien ne se fait en une seule fois, il faut régulièrement revenir sur des étapes et ne jamais perdre de vue qu’une application ne sert qu’à une chose : répondre à une problématique métier. Ainsi, si ces efforts sont grands, les gains le sont tout autant : meilleure compréhension entre les métiers et les développeurs, avec comme pierre angulaire l’ubiquitous langage, meilleure organisation des applications, des process métiers et des équipes dev (phases de découverte, event storming, context map, …) et enfin un code plus maintenable , testable et une expression claire des besoins métier.
Comment Inside répond à ces enjeux ?
En interne tout d’abord, nous avons la possibilité d’améliorer nos pratiques, notamment avec la participation à DDD Europe. Il s’agit d’une conférence de premier plan dédiée à la modélisation et à la conception de logiciels. Elle a pour but de partager les meilleures pratiques, des retours d’expériences et les dernières avancées dans le domaine du Domain-Driven Design. Il était par exemple fortement question de Conway Law cette année, cette loi qui dit que « les organisations qui conçoivent des systèmes tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation. ». Par exemple, si nous séparons une organisation en 3 départements (UI, backend, base de données), nous aurons forcément un système à 3 composantes qui communiquent (difficilement) entre elles. Donc, lors de la structuration d’une application ou d’un outil, il faut penser à donner de la flexibilité. Les structures organisationnelles ayant tendance à changer, il est nécessaire de réfléchir à long terme.
En externe, Inside propose deux grands types de prestations. La première est orientée vers les développeurs, pour les acculturer au DDD et leur proposer un accompagnement autour des patterns tactiques et de l’ubuquitous language, de l’amélioration du code jusqu’à la proposition de code. La seconde porte sur la partie stratégique, qui peut être initiée à la suite de la première prestation. Soit lorsque la partie tactique remonte un besoin en montrant que la partie stratégique (en amont) a été mal faite (il s’agit donc d’une récupération de Legacy). Mais la demande peut également provenir directement du client. Enfin, nous proposons également une formation sur étagère en 2 jours pour les développeurs : comprendre que le développement est la transcription du contexte métier en code, comprendre la notion d’ubiquitous language, l’importance de bien exprimer le métier dans le code, comment les architectures en couches permettent l’isolation du domaine et de la technique, connaître les concepts de value object et d’entité….
Vous souhaitez échanger avec nos experts autour du Domain Driven Design, c’est par ici !