Définir une vision et un langage partagé pour toutes les parties prenantes d’un projet. C’est l’objectif du Domain Driven Design, qu’on appelle aussi DDD. Il permet de mieux appréhender la complexité du processus métier et de l’implémenter dans le code.
Zoom sur ce concept qui a révolutionné la construction de logiciels et d’applications.
En quoi consiste le Domain Driven Design (DDD) ?
C’est à Eric Evans qu’on doit la théorisation du Domain Driven Design, dans son oeuvre “Tackling complexity in the Heart of Software“, publié en 2003. Cet ouvrage de référence, qu’on appelle aussi le “blue book” a permis de poser les jalons de ce concept qui replace le métier au cœur de la conception. L’auteur entend plus précisément démocratiser la conception pilotée par le domaine, c’est-à-dire le métier.
Concrètement, cela sous-entend qu’il faut réconcilier l’équipe de développeurs et les experts métiers, afin de parvenir à un langage commun compréhensible des deux côtés. C’est une manière de lier le fonctionnel et le code qui révolutionne la façon de mener un projet.
L’avis de l’expert theTribe
“Le blue book est un livre qui a véritablement marqué l’histoire du développement logiciel. Il expose les concepts fondamentaux du Domain Driven Design : le langage ubiquitaire, les patterns tactiques, les patterns stratégiques…
Son ambition : placer le métier au cœur de la conception, afin d’améliorer la communication entre les experts métier et la partie delivery. Et ce grâce une terminologie commune qu’on appelle langage ubiquitaire”. Emmanuel Martin, Technical Lead
Pourquoi utiliser le DDD ?
Le Domain Driven Design caractérise une manière de penser le code et de concevoir des logiciels. Et si elle est aussi populaire, c’est bien qu’elle présente des avantages non négligeables.
Un langage commun 🤝
Trop souvent, la communication entre les experts métier et les développeurs est marquée par une certaine incompréhension. D’un côté, les développeurs utilisent un langage technique qui peut paraître opaque et inaccessible. De l’autre, l’expert fonctionnel s’exprime avec des termes qui sont propres à son domaine.
À cause de ces différences de terminologie, il peut sembler qu’un fossé existe entre ces deux parties prenantes.
Le DDD permet précisément de remédier à cette problématique, en favorisant la communication grâce à un langage commun, que tout le monde peut comprendre. C’est ce qu’on appelle le langage ubiquitaire, qui prend la forme d’un glossaire dont les termes sont modélisés puis intégrés au code source.
L’avis de l’expert theTribe
“Parfois, les experts métier et les développeurs ont du mal à communiquer, car il y a des problèmes de sens. Grâce au Domain Driven Design, on place les termes du métier au centre et on normalise le jargon pour que chacun puisse l’utiliser. Ensuite, on utilise ce jargon dans le développement à travers le code.
Un des objectifs du DDD, via le lexique, c’est de permettre à quelqu’un du métier de comprendre le code sans avoir de connaissances techniques. Cela rend le code plus explicite et lisible, y compris pour les personnes extérieures.” Emmanuel Martin, Technical Lead
La qualité du projet dans le temps ⏳
Grâce au DDD, le modèle est modulable et flexible dans le temps, il s’inscrit dans un processus d’amélioration continue. Tout est réutilisable et c’est ce qui permet d’enrichir le modèle au fil du temps. Parce que le domaine métier évolue souvent, la modélisation elle aussi doit changer. Cette approche est très semblable à la méthode Agile, qui met l’accent sur le progrès permanent et l’échange constant entre les équipes.
Les phases de conception d’un projet avec une approche Domain Driven Design ?
Adopter l’approche Domain Driven Design, c’est suivre plusieurs étapes dans le cadre de la création d’une application mobile ou la création d’une application web :
1. Compréhension du métier 🤔
Le métier est le point d’entrée de l’approche, puisque c’est lui qui est placé au centre de la conception. L’objectif est donc, dans cette première phase, d’améliorer la connaissance métier. Pour cela, il faudra récolter le plus d’informations possibles auprès des experts métiers, au travers d’interviews et d’entretiens menés avec eux. Cela permettra de mettre en lumière les concepts fondamentaux liés à leur expertise, et les expliciter.
C’est aussi le moment où il faut constituer un glossaire, où on pourra trouver toutes les définitions des termes métiers.
2. Modélisation 📝
Après avoir extrait l’essentiel des informations grâce aux experts métiers, il est temps de passer à la modélisation. Cette phase fait en quelque sorte office de trait d’union entre les développeurs et la partie métiers.
Ici, on cherche à simplifier les définitions et les liens entre les concepts. Il y a donc un impact sur les définitions et il faut le partager avec le métier. La modélisation permet en outre de gérer la complexité en organisant l’information et en la classant.
Dans un modèle, on trouve plusieurs éléments indispensables :
- Les Aggregate Roots,
- Les services du domaine,
- Les repositories,
- Les specifications,
- Les événements du domaine.
3. Implémentation et communication 🗣
Il faut ensuite partager l’information auprès de toutes les personnes qui participent au projet, afin qu’elles soient toutes alignées sur la connaissance métiers. Lors de cette phase, de nouvelles contraintes surgissent (par exemple des soucis de performance, des contraintes d’infrastructure…).
Ces dernières peuvent pousser à faire évoluer le modèle et donc le glossaire.
L’avis de l’expert theTribe
“Le DDD fonctionne sous forme de triptyque : on met d’abord l’accent sur la compréhension du métier, puis on fait la modélisation, avant de finir par l’implémentation. Ce qui est essentiel, c’est que les éléments restent cohérents entre eux tout le temps, que le triptyque reste synchrone en permanence”. Emmanuel Martin, Technical Lead
Quels sont les grands concepts du Domain Driven Design ?
Pour mieux comprendre le DDD et mieux adopter cette approche au sein de votre entreprise, il faut connaître ses grands principes.
👉 Ubiquitous language
Il s’agit d’employer le vocabulaire et les notions des clients et experts métiers à la fois dans les discussions, mais également dans le code source.
C’est un langage partagé que toutes les parties prenantes utilisent.
👉 Bounded Context
Les bounded contexts permettent de diviser un modèle de domaine trop vaste en plusieurs modèles plus petits. Ils doivent absolument être découpés en partant du métier et non pas de la technique.
👉 DDD Tactical Patterns
Les patterns tactiques aident à exprimer les problématiques métiers dans le code. Ils regroupent : les Entités, les Value Objects, les Services, les Modules, les Agrégats / Factories / Repositories.
👉 DDD Patterns stratégiques
Ils représentent les différents patterns de communication entre les bounded contexts.
