Il y a plusieurs années, un concepteur de logiciels talentueux a ajouté une fonctionnalité d'édition qu'il a appelée "Divide and Conquer" à un programme de mise en page de journaux populaire.
Cette fonctionnalité était bien conçue, mais personne ne l'a utilisée. Voici pourquoi :
- Le nom "divide and conquer" n'avait aucun sens en relation avec la mise en page de journaux.
- Personne ne pouvait expliquer ce que faisait la fonctionnalité ou pourquoi on l'utiliserait.
- Personne n'avait demandé la fonctionnalité et personne n'en voulait.
Essentiellement, plus d'attention a été accordée à ce qui pouvait être fait avec le programme plutôt qu'à pourquoi cela devrait être fait.
Qu'est-ce que le Domain-Driven Design (DDD) ?
Le logiciel est censé nous faciliter la vie. Il peut rationaliser et automatiser les processus du monde réel ou répondre aux intérêts des utilisateurs spécifiques. Les domaines que le logiciel vise à travailler sont les domaines pour lesquels le logiciel est destiné. Par exemple, le domaine des logiciels de Digital Audio Workstation (DAW) est l'industrie de l'enregistrement audio.
Un développeur de logiciels nommé Eric Evans a reconnu le besoin de comprendre le domaine du logiciel. Pour introduire l'approche DDD, il a écrit un livre intitulé "Domain-Driven Design: Tackling Complexity in the Heart of Software".
📖 Dans son livre, Evans dit :
"Le cœur du logiciel est sa capacité à résoudre les problèmes liés au domaine pour son utilisateur. Toutes les autres fonctionnalités, bien qu'elles puissent être vitales, soutiennent ce but fondamental."
Donc, dans notre exemple de mise en page de journal ci-dessus, vous n'avez pas besoin d'être un éditeur de mise en page professionnel pour concevoir un logiciel de mise en page utile. Mais vous devez comprendre comment les éditeurs de mise en page font leur travail si vous voulez créer un logiciel qui reflète leurs processus et procédures du monde réel.
Toute fonctionnalité au-delà de ce dont ils ont besoin ajoute peu ou pas de valeur.
Principes Directeurs du Domain-Driven Design
Le Domain-Driven Design consiste essentiellement à développer des logiciels qui modélisent des systèmes et des processus du monde réel. Cette approche est basée sur les principes directeurs DDD suivants :
1️⃣ Concentrez-vous sur le domaine principal : Avant de commencer à coder, parlez aux personnes qui travaillent dans ce domaine. Ils peuvent vous aider à définir tous les processus, procédures et terminologies de ce domaine.
2️⃣ Réduisez la complexité en basant les conceptions sur des modèles de domaines : Lorsque vous comprenez le domaine commercial, créez un modèle qui est le reflet du domaine réel.
3️⃣ Parlez une langue commune : Dans son livre, Evans parle de l'importance du langage ubiquitaire. Tout le monde impliqué dans le projet devrait utiliser le même langage pour parler du domaine.
Termes Clés du Domain-Driven Design
Voici quelques termes clés communs utiles pour apprendre le DDD :
🖊️ Domain logic : Aussi appelée logique métier. C'est le but de votre modèle et de la conception de votre logiciel.
🖊️ Design Patterns : Si un code existant résout un problème similaire à celui sur lequel vous travaillez, adaptez-le à votre usage.
🖊️ Context : Le cadre ou l'environnement qui détermine la signification d'un mot, d'une action ou d'une fonctionnalité dans le domaine logiciel.
🖊️ Bounded Contexts : Les grands projets ont généralement de nombreux modèles qui doivent être intégrés. Une limite de contexte définit le cadre logique dans lequel un modèle peut évoluer.
🖊️ Context mapping : Un document, graphique ou diagramme qui décrit les relations entre de multiples contextes limités.
🖊️ Entities : Un objet de domaine défini par son identifiant unique plutôt que par des attributs.
🖊️ Value Objects : Un objet inchangéable qui a des attributs, mais pas d'identité distincte.
Avantages du Domain-Driven Design ✅
Le principal avantage du DDD est qu'il amène tout le monde à utiliser le même langage. Lorsque les équipes de développement utilisent le même langage que les experts du domaine, cela conduit à une conception de logiciel qui a du sens pour l'utilisateur final. Comme la terminologie de l'application correspond aux activités du monde réel, il y a moins de confusion et les utilisateurs comprendront comment utiliser le produit plus rapidement.
Autres bénéfices du DDD incluent :
- Alignement entre les affaires et le développement : L'utilisation du même langage améliore la communication et la compréhension entre les développeurs et l'équipe commerciale.
- Protection des connaissances du domaine : Les connaissances précieuses ne sont pas perdues lorsque les équipes passent à d'autres projets ou lorsque de nouvelles personnes sont amenées à maintenir des projets existants.
- Plus de flexibilité : Les définitions et limites de contexte facilitent la gestion des changements de besoins car tout le monde a la même compréhension du domaine commercial.
- Facilité de suivi : Une meilleure communication et un ensemble commun de terminologie facilitent le suivi de l'implémentation des exigences.
- Meilleur équilibre de l'application : L'accent mis sur les besoins et les recommandations du domaine garantit que le logiciel résultant est équilibré pour répondre aux besoins et aux attentes des clients.
- Meilleur code : Suivre une approche DDD donne finalement un code plus propre et plus fiable.
Inconvénients du Domain-Driven Design 🥴
Le DDD offre de nombreux avantages, mais il n'est pas nécessairement adapté à tous dans toutes les situations. Quelques inconvénients incluent :
- Exige une connaissance approfondie du domaine : Il est nécessaire d'avoir au moins un expert du domaine dans l'équipe.
- Fonctionne seulement si le domaine est complexe : Si le domaine est relativement simple, le DDD pourrait être un surinvestissement en temps.
- Peut ne pas bien fonctionner dans des projets hautement techniques : Quand le projet est techniquement complexe, il est difficile d'établir un langage commun compréhensible par les personnes du côté commercial.
- Peut être chronophage : Sauf si vos développeurs sont déjà des experts du domaine, ils devront passer beaucoup de temps avec l'équipe commerciale pour comprendre complètement le domaine.
Conseils pour la mise en œuvre du Domain-Driven Design 🤠
Le DDD n'a pas besoin d'être écrasant. Si vous êtes intéressé par l'adoption des principes DDD dans votre organisation, utilisez ces conseils pour bien démarrer :
- Commencez petit : Ne tentez pas d'appliquer le DDD partout d'un seul coup. Commencez par un morceau de votre application et commencez à y appliquer les principes DDD.
- Apprenez et améliorez continuellement : Après avoir commencé petit, vous pouvez construire sur ce que vous avez appris et commencer à élargir votre portée.
- Utilisez des outils de diagrammation DDD : Le DDD vous aide à modéliser des systèmes et des processus du monde réel. Utiliser une solution de diagrammation intelligente comme Lucidchart rend non seulement la modélisation plus facile, mais donne également aux parties prenantes une vue claire du système ou de l'application que vous mappez.
Si votre organisation souhaite créer un logiciel qui s'intègre bien dans son domaine commercial prévu, envisagez de mettre en œuvre le Domain-Driven Design. Même si le DDD n'est pas adapté pour vous, il vaut toujours la peine d'apprendre car il peut vous aider à améliorer la communication entre vos équipes de développement et les experts du domaine.
