Dans cet article, nous verrons:
1. Ce qu’est le Domain-Driven Design
2. L’approche DDD dans une architecture microservices
3. Avantages & inconvénients de l’approche DDD
Qu’est-ce que le Domain-Driven Design ?
Le DDD n’est pas une méthode de modélisation mais plutôt une façon de penser ou encore une philosophie de conception. Cette approche est d’ailleurs décrite dans le livre Domain Driven Design d’Eric Evans. Son objectif est de définir une vision et un langage partagés par toutes les personnes impliquées dans l’élaboration d’une application, afin de mieux en appréhender la complexité.
On a beaucoup parlé de Model First mais alors que le MDA (Model Driven Architecture) repose sur des outils de génération de code, concernant le DDD, il est question de pratiques de conception et non d’outils.
Domain-Driven Design est préconisé pour le développement de systèmes complexes principalement axés sur des activités, des tâches, des événements, des règles métiers importantes et implique la collaboration entre experts du domaine et experts en conception/architecture. Quand on sait que l’absence d’une compréhension partagée entre eux constitue un obstacle majeur à la réussite des projets, Domain-Driven Design est la méthodologie pour remédier à cet obstacle.
DDD s’attache également à réduire le nombre d’entités par domaine. En effet, travailler dans des contextes plus petits permet de diviser la complexité.C’est en ça que les approches DDD sont d’autant plus pertinentes si vous implémentez des Microservices.
L’approche DDD dans une architecture microservices
L’architecture microservices est une approche attractive pour construire et faire évoluer des systèmes à grande échelle, avec un grand nombre d’équipes de développeurs qui doivent pouvoir travailler en relative autonomie pour livrer des fonctionnalités efficacement et indépendamment les unes des autres, sans mettre en péril l’ensemble de l’application.
Passer à une architecture microservices permet également de moderniser son application et d’augmenter ses capacités d’évolution, d’adaptation et de maintenabilité.
La conception stratégique offerte par le DDD permet une bonne conception des microservices dans laquelle les méthodologies agiles ont toute leur place. Le Product Owner (directeur produit) dispose d’une vision globale produit/service et il est le garant de sa qualité. Il permet un vrai contact avec les équipes métiers et techniques mais aussi avec l‘utilisateur final. Il recueille ses besoins et priorise les différents objectifs qu’il gère dans un « backlog ». Il établit la priorité des fonctionnalités à développer ou à corriger et attribue les tâches en fonction des compétences de chacun. Avoir une interaction avec le métier permet de prendre les bonnes décisions, de réaliser le bon produit, de le tester régulièrement, de le montrer aux parties prenantes et de réajuster au fur et à mesure.
En matière de microservices, le focus est souvent mis sur les technologies, alors que le point clé consiste à bien définir le contour des services. Ce n’est pas simple et c’est précisément pour cela que l’approche Domain-Driven Design est précieuse pour bien guider le découpage.
Avec les pratiques DevOps, les conteneurs et le Domain-Driven Design, les microservices offrent clairement une meilleure agilité et une productivité plus optimale. Chaque composante étant segmentée, les décisions d’architecture peuvent être prises indépendamment les unes des autres, tout en ayant l’opportunité de relayer la gestion des dépendances aux conteneurs pour faciliter l’intégration.
Comme l’explique Ange Guyager, Team Leader chez SoftFluent et expert Microservices
L’approche DDD préconise une modélisation basée sur les cas d’usage. Le DDD traite chaque problème comme un domaine à part entière avec un périmètre clairement identifié. Chacun de ces contextes sera représenté par un microservice qui aura la charge de répondre à ce problème et uniquement à celui-ci
Les couches dans les microservices sont, pour leur part, assez standards. On retrouvera une couche d’accès aux données si besoin, une couche métier, une couche d’application, une couche d’infrastructure et une couche de mise à disposition (WebAPI par exemple).
En nous appuyant sur la séparation des modèles qu’offre le DDD, nous rejoignons le concept à la base des microservices.
Avantages et inconvénients de l’approche Domain-Driven Design
Points positifs de l’architecture DDD
- La modélisation du domaine est au plus proche de la problématique des utilisateurs avec des règles et des comportements clairement identifiés, facilitant les échanges entre les profils fonctionnels et techniques.
- La modélisation du domaine mettant l’accent sur les interactions, il est aisé de mettre en œuvre une interface utilisateur orientée tâches/activités.
- Les échanges sur les fonctionnalités sont facilités avec les utilisateurs.
- Les développeurs bénéficient d’une compréhension du métier rien qu’à la lecture du code du domaine. Un nouveau développeur peut donc plus facilement appréhender le code et le fonctionnel de l’application.
- Les règles métier étant explicites et concentrées dans une couche bien définie de l’application, elles sont plus facilement testables par un outil de tests fonctionnels automatisés.
Points négatifs de l’architecture DDD
- Le modèle contenant beaucoup de relations entre entités, la remontée d’information ou la collecte de données peuvent s’avérer plus compliquées avec potentiellement des problèmes de performances du système en lecture.
- Le DDD nécessite une courbe d’apprentissage relativement longue pour avoir une compréhension suffisante des règles métier et des problèmes posés afin les séparer clairement et de manière adéquate.
La plus grande difficulté dans la définition de microservices sera de définir correctement la granularité : si la couverture fonctionnelle des services est trop large ce ne sont plus des microservices, à contrario si la granularité est trop fine et que cela engendre une multiplication des échanges entre microservices, on perdra en performance avec une multiplication des échanges
précise Ange Guyader
En résumé
Adopter une approche DDD dans le développement de logiciels, commence par :
La compréhension du métier :
Mettre en évidence les concepts fondamentaux en vue d’améliorer les processus métier et parler le même langage.
La modélisation (trait d’union des expertises métier et logicielle) :
La modélisation impose de classer l’information, de la ramener à un niveau granulaire, de l’organiser en modules logiques, et de traiter ces modules un à un.
La communication
Ce modèle doit être partagé à l’ensemble des parties prenantes (les experts métier, les développeurs, etc.) de manière précise et exhaustive dans un langage commun (ubiquitous language) compréhensible par tous.
