Le DDD ou Domain-Driven Design est un concept qui se focalise sur un problème et la manière dont l’entreprise va le résoudre. C’est une solution gagnante lorsqu’il s’agit de faire face à la complexité des environnements commerciaux.
Les entreprises rencontrent souvent des problèmes complexes que la résolution peut mettre beaucoup plus de temps. En effet, l’interconnexion entre les divers objectifs commerciaux rend plus ardu le développement logiciel. La complexité des environnements commerciaux peut entraîner une mauvaise prise de décision. La conception pilotée par le domaine ou DDD vise justement à faire face à ce genre de difficulté. Le concept a été inventé par un certain Eric Evans, en 2004, lorsqu’il a écrit son livre intitulé : Domain-Driven Design: Tackling Complexity in the Heart of Software. Le présent dossier va vous faire découvrir tout ce qu’il y a à savoir autour du sujet.
Qu’est-ce que la conception pilotée par le domaine ou DDD ?
Avant de définir ce qu’est le DDD, penchons un peu sur ce que signifie le terme domaine dans le présent contexte. En fait, selon Evans, le domaine peut se définir comme étant une sphère d’activités ou de connaissances spécifiques définissant un ensemble d’exigences, de terminologie et de fonctionnalités communes. La logique du logiciel doit fonctionner sur la base de ces activités ou connaissances afin de résoudre un problème.
Dans ce concept, il faut concevoir le logiciel en tenant compte de la constante évolution du modèle. Ce qui implique une bonne stratégie et une organisation minutieuse de la logique destinée à résoudre le problème. Les microservices sont une concrétisation d’une telle approche.
Dans son écrit, Evans cite les trois objectifs principaux sur lesquels repose le DDD :
- Le projet a pour objectif principal le domaine de base et la logique du domaine.
- Les modèles du domaine servent de bases pour les conceptions complexes.
- En vue de créer un modèle d’application capable de résoudre les divers problèmes dans leur complexité, il faut opter pour une collaboration étroite entre toutes les parties prenantes. Les parties prenantes concernent particulièrement les experts techniques et les experts du domaine.
Les différentes couches qui composent un DDD
Pour mieux gérer la complexité des données, l’approche DDD se subdivise en 4 couches dont :
La couche d’interface utilisateur d’un DDD
C’est la partie visible de l’application. Cette couche affiche les données ainsi que la capture des commandes de l’utilisateur telles que les produits, le mode d’expédition (s’il s’agit d’une vente en ligne), etc.
La couche d’application
La couche d’application ne contient pas de logique métier. Elle ne connaît pas non plus les règles de domaine. Elle s’occupe tout simplement d’organiser et déléguer les objets de domaine pour que ceux-ci fassent leur travail. C’est aussi l’unique couche à laquelle d’autres contextes délimités peuvent accéder.
Couche domaine
Il s’agit de la couche qui dispose de la logique métier, de l’état métier ainsi que des règles métier. La couche domaine renferme de ce fait la totalité des informations en vue de l’analyse de la rentabilisation.
La couche infrastructure
C’est là que se concrétise l’implémentation de toutes les fonctionnalités techniques nécessaires à l’application en matière de prise en charge des couches supérieures. Elle assure également la communication entre les couches, la messagerie, la persistance, etc.
Fonctionnement du DDD, des termes importants à retenir
Afin d’avoir une vision plus claire sur ce qu’est le DDD, il importe de se familiariser avec les termes les plus pertinents à savoir :
Langage omniprésent en matière de DDD
Comme on l’a dit plus haut, la collaboration entre les différents acteurs est un des principes de base du DDD. Pour ce faire, le domaine doit trouver un terrain d’entente où tous les membres de l’équipe, technique et commerciale, peuvent se comprendre et s’entendre. Ce langage s’appelle langage omniprésent.
En effet, les experts du domaine ont tendance à utiliser leur propre jargon technique que l’équipe commerciale ne comprend pas. De son côté, cette dernière possède sa propre terminologie pour décrire le domaine. Ce qui pourrait engendrer un réel problème de langage.
Avec l’utilisation du langage omniprésent dans le DDD, l’interaction sera plus facile et supprime toute ambiguïté.
Entités
Dans le DDD, les combinaisons de données et de comportements s’appellent entités. Cela peut être un utilisateur ou un produit. Les entités possèdent une identité ainsi qu’un fil conducteur de continuité. Leur définition part plutôt de ce qui elles sont et non pas uniquement de leurs attributs.
Bien que leurs attributs subissent des mutations et que leurs cycles de vie changent, les entités ne perdent jamais leur identité. L’identité est préservée grâce à une clé unique ou une combinaison d’attributs uniques.
Logique de domaine
La logique de domaine, aussi connu sous le nom de logique métier, est l’aboutissement de tout travail de modélisation. Dans cette logique, il existe des règles qu’on appelle règles métier, destinées à définir la manière dont on crée, conserve et modifie les données.
DDD et service de domaine
Le service de domaine comporte également une logique métier. C’est en fait, une couche supplémentaire faisant partie intégrante du modèle de domaine. Il y a aussi ce qu’on appelle service d’application, qui est une autre couche supplémentaire mais ne contenant pas de logique de domaine. Ce dernier a toutefois pour rôle de coordonner l’activité de l’application.
Contexte délimité d’un DDD
En matière de DDD, le contexte délimité forme le modèle central. C’est ce qui renferme la complexité de l’application. On y trouve la gestion des grands modèles et des équipes. C’est aussi dans le contexte délimité que s’opère l’implémentation du code une fois que le domaine et les sous-domaines sont définis.
En réalité, celui-ci définit l’applicabilité d’un sous-domaine spécifique. De ce fait, le changement d’un sous-domaine au sein du contexte délimité n’implique aucun changement de l’ensemble du système.
Modèles de conception d’un DDD
Les modèles de conception sont intrinsèques à tout projet orienté objet afin de pouvoir réutiliser le code ultérieurement. En principe, celui qui a créé le programme a probablement déjà trouvé la solution en cas de difficulté, c’est le modèle de conception.
Trouver la solution au problème consiste tout simplement à le décomposer pour obtenir les éléments initiaux. En plus, la solution obtenue à partir du modèle pourra servir pour résoudre d’autres problèmes dans le futur.
Modèle de domaine d’un DDD
Le modèle de domaine quant à lui rassemble toutes les idées, connaissances, données, mesures ainsi que les objectifs qui tournent autour du sujet à résoudre. C’est dans le modèle de domaine que se trouvent les règles et tous les modèles servant à la gestion de la logique métier. C’est également l’ensemble de règles et de modèles avec lesquels les experts vont essayer de répondre aux exigences de l’entreprise.
Sous-domaine
Comme son nom l’indique, il s’agit de la décomposition du domaine. En fait, un domaine est formé par un certain nombre de sous-domaines faisant référence à des composants de la logique métier. L’exemple ci-après peut vous aider à mieux cerner le sujet.
Voici une entreprise qui travaille dans le domaine du commerce électronique. L’entreprise dispose de plusieurs sous-domaines tels que le catalogue de produits, l’inventaire, la livraison, etc.
Objets de valeur
Lorsque les objets décrivent des caractéristiques mais ne possédant pas d’identité, on les appelle objets de valeur. Contrairement aux entités, les objets de valeur se soucient plus de ce qu’ils sont et non de ce qui ils sont. Leur création repose sur la validité des données utilisées dans la création ainsi que la manière dont celles-ci respectent les invariants de l’entreprise.
Agrégats
On parle d’agrégats lorsqu’il s’agit de collectionner des entités et des objets de valeur en vue de limiter la violation des invariants. Ils représentent un ensemble formant une frontière transactionnelle. Au sein d’un agrégat, il existe une entité appelée racine d’agrégat. C’est cette entité qui fait office d’intermédiaire avec l’extérieur de l’agrégat. La racine contrôle également toute forme d’interaction avec d’autres objets.
Dépôt
La création d’une interface servant à cacher les détails de l’implémentation au client est nécessaire dans un DDD. Cela permet de récupérer les objets de la persistance, que ce soit une mémoire, une base de données ou un système de fichiers. Toutes les définitions d’interface de référentiel doivent pourtant se trouver dans la couche de domaine. Par contre, leurs implémentations appartiennent à la couche d’infrastructure.
Quels sont les avantages d’un DDD ?
Les avantages de la conception pilotée par le domaine sont nombreux. Tout d’abord, le DDD facilite la communication par le biais du langage omniprésent. L’équipe utilise plutôt des termes connus et compris par tous au lieu d’emprunter des jargons techniques compliqués.
Un autre avantage du DDD, c’est sa flexibilité. Étant un projet orienté objet, tout part donc de l’objet. Ce dernier étant modulaire et en cage. Ce qui permet à l’équipe de modifier l’ensemble du système et l’améliorer suivant les besoins des clients.
Par ailleurs, il faut souligner qu’une telle approche permet aux utilisateurs de se connecter directement au domaine. A la différence d’UI/UX, le concept piloté par le domaine aboutit à une application adaptée à un domaine particulier et bien défini.
Toutefois, on décèle quelques inconvénients quant à son adoption.
Ses inconvénients
Avant de s’attaquer à une telle approche, il faut disposer d’une connaissance approfondie du domaine. Le domaine étant le centre de l’application à créer, il va falloir, au moins un élément de l’équipe, qui soit spécialiste du domaine, connaissant toutes ses spécificités techniques. Parfois il en faut plus qu’un pour mener à bien le projet.
De fil en aiguille, le DDD ne peut pas toujours être la meilleure solution, notamment pour les projets hautement techniques. Il se peut que l’équipe soit dans l’impasse lorsque la complexité de l’application est élevée.
- Partager l'article :