Le Domain Driven Design

Nidhal Daghrir
7 avril 2022
Performance et Technologies
Aucun commentaire

Définition

Encore appelé DDD, le Domain Driven Design se traduit en français par l’expression « conception dirigée par le domaine » ou « conception pilotée par le métier ». C’est une approche en conception logicielle guidée par le métier. Elle est créée pour résoudre la complexité du développement logiciel. L’approche du DDD a été introduite au départ et rendue publique par le programmeur Eric Evans, dans son livre publié en 2004 et intitulé : « Domain-Driven Design : Tackling Complexity in the Heart of Software ». La conception pilotée par le métier est l’expansion et l’application du concept de domaine, tel qu’il s’applique au développement de logiciels. Son but est ainsi de faciliter la création d’applications complexes.

Principes de base du DDD

Trois principes constituent le Domain Driven Design :

La concentration sur le domaine principal et la logique du domaine. Autrement dit, le cœur principal du projet est le domaine de base et la logique du domaine ;
L’assise des conceptions complexes sur des modèles du domaine ;
La collaboration capitale entre les experts techniques et ceux du domaine pour créer un modèle d’application qui résoudra des problèmes de domaine émergents.

Télécharger le livre blanc « l’explosion des microservices »

Concepts de base du DDD

La conception pilotée par le domaine d’Evans définit plus en détail quelques termes courants utiles pour décrire et discuter des pratiques DDD, et notamment :

Le contexte : il désigne le cadre dans lequel un mot ou une déclaration apparaît. Cela est déterminant pour sa signification. Les déclarations sur un modèle ne peuvent être interprétées que dans un contexte bien défini.
Le modèle : il s’agit d’un système d’abstractions qui décrit des aspects choisis d’un domaine. Le modèle renferme tous les éléments qui composent un domaine et peut être utilisé pour résoudre des problèmes liés à ce domaine.
Le langage ubiquitaire : il renvoie à un langage structuré autour du modèle du domaine. Il est utilisé par tous les membres de l’équipe pour connecter toutes leurs activités avec le logiciel. Le langage ubiquitaire renvoie alors au même domaine linguistique que celui qu’utilisent les experts et les développeurs lorsqu’ils parlent du domaine dans lequel ils œuvrent. Il est donc question, pour les experts du domaine, d’utiliser le même jargon.
Le Contexte délimité : il fait référence à une limite décrite (comme, en général, un sous-système ou le travail d’une équipe spécifique) dans laquelle un modèle particulier est défini et susceptible d’être appliqué.

Blocs de construction du DDD

La conception axée sur le domaine définit également un certain nombre de concepts de haut niveau qui peuvent être utilisés parallèlement pour créer et modifier des modèles de domaine. Il s’agit notamment des concepts suivants : Entité – Objet de valeur – Événement de domaine – Agrégat – Service – Référentiels – Usines – Logique de domaine – Modèle de domaine – Sous-domaine – Modèles de conception – Contextes délimités – Langue omniprésente – Langage ubiquitaire – Objets de valeur et agrégats – Service de domaine – Dépôt.

Couches architecturales du Domain Driven Design

Le Domain Driven Design préconise de séparer le code en couches. Chaque couche remplit une fonction particulière et utilisable par d’autres couches de façon à mutualiser le code suivant une logique.

Les 4 couches sont :

L’interface utilisateur qui présente les informations observables du système ;
La couche d’application, responsable de la coordination de l’activité d’application ;
Le domaine qui contient l’information sur le domaine ;
L’infrastructure qui recèle les détails d’implémentation technique.

Que retenir du Domain Driven Design ?

Le Domain Driven Design est un modèle d’application qui indique une conception encore plus approfondie du métier. Il permet donc de se focaliser sur le métier plutôt que sur la technique.

Quelques questions complémentaires

Comment Domain Driven Design peut-il améliorer la collaboration entre les équipes techniques et les experts métiers ?

Domain Driven Design (DDD) facilite la collaboration entre les équipes techniques et les experts métiers en introduisant un langage commun appelé le « langage ubiquitaire ». Ce langage est partagé par tous les membres de l’équipe et est basé sur les concepts et terminologies spécifiques du domaine de l’application. Cela permet d’éliminer les malentendus et de s’assurer que tout le monde a la même compréhension des exigences et des objectifs du projet.

En utilisant des modèles de domaine partagés, les équipes peuvent travailler ensemble pour affiner et améliorer la conception de l’application. Les experts métiers apportent leur connaissance approfondie du domaine, tandis que les développeurs traduisent ces concepts en implémentations techniques. Cette approche itérative et collaborative renforce la communication, l’alignement des objectifs et la cohésion d’équipe.

Quels sont les principaux défis à surmonter lors de la mise en œuvre de Domain Driven Design dans une organisation ?

L’implémentation de DDD dans une organisation peut présenter plusieurs défis :

Complexité du domaine : Comprendre et modéliser des domaines complexes nécessite du temps et des efforts de la part de toutes les parties prenantes.
Résistance au changement : Les équipes peuvent être réticentes à adopter de nouvelles méthodes de travail et de nouvelles terminologies, surtout si elles sont habituées à des approches plus traditionnelles.
Alignement des équipes : Assurer une collaboration étroite et continue entre les développeurs et les experts métiers peut être difficile, surtout dans les grandes organisations.
Formation et compétences : Les équipes doivent être formées aux principes et aux pratiques de DDD, ce qui peut nécessiter des investissements en temps et en ressources.
Maintenance et évolution : Maintenir et faire évoluer les modèles de domaine au fil du temps pour refléter les changements dans le domaine métier peut être un processus complexe et continu.

Comment DDD s’intègre-t-il avec d’autres méthodologies de développement logiciel comme Agile ou DevOps ?

Domain Driven Design (DDD) s’intègre bien avec des méthodologies de développement logiciel comme Agile et DevOps en renforçant plusieurs principes clés :

Agilité : DDD encourage les itérations courtes et fréquentes, avec des boucles de rétroaction rapides entre les développeurs et les experts métiers. Cela correspond bien aux cycles de développement Agile, où les équipes travaillent sur des incréments de produit en constante amélioration.
DevOps : En promouvant des modèles de domaine bien définis et une architecture modulaire (par exemple, à travers des microservices), DDD facilite le déploiement continu et l’intégration continue, éléments clés de DevOps. La clarté des responsabilités et des frontières des services permet une automatisation plus efficace des déploiements et des tests.

Quelles sont les erreurs courantes à éviter lors de l’application des principes de DDD ?

Quelques erreurs courantes à éviter lors de l’application de DDD incluent :

Sauter l’étape de découverte du domaine : Négliger l’étape cruciale de compréhension approfondie du domaine et des besoins métiers peut conduire à des modèles de domaine inappropriés ou incomplets.
Ignorer le langage ubiquitaire : Ne pas investir dans la création et l’utilisation d’un langage commun entre les équipes techniques et métiers peut provoquer des malentendus et des erreurs de communication.
Mélanger les responsabilités : Ne pas respecter les principes de séparation des responsabilités et de modularité peut entraîner une architecture monolithique difficile à maintenir et à faire évoluer.
Négliger la documentation : Une mauvaise documentation des modèles de domaine et des décisions de conception peut compliquer la maintenance et l’évolution du système.

Comment mesurer le succès de la mise en œuvre de Domain Driven Design dans un projet logiciel ?

Pour mesurer le succès de la mise en œuvre de DDD, on peut utiliser plusieurs indicateurs et métriques :

Alignement des modèles de domaine : Évaluer si les modèles de domaine reflètent fidèlement les concepts et les processus métiers et si les utilisateurs finaux et les experts métiers les trouvent intuitifs et utiles.
Qualité du code : Mesurer la modularité, la réutilisabilité et la maintenabilité du code. Des modèles de domaine bien conçus devraient faciliter les modifications et les extensions du système.
Vitesse de développement : Suivre le temps nécessaire pour livrer des fonctionnalités ou résoudre des problèmes. Une bonne mise en œuvre de DDD devrait améliorer l’efficacité et la rapidité de développement.
Satisfaction des parties prenantes : Recueillir des retours réguliers des utilisateurs finaux, des experts métiers et des développeurs sur la qualité et l’utilité du produit.
Taux de défauts : Suivre le nombre et la gravité des bugs et des problèmes rencontrés. Une implémentation réussie de DDD devrait réduire le nombre de défauts liés à une mauvaise compréhension du domaine.