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.
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.
_____________________________________________________________________________
Tout simplement “Agile Fan” !
N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités !