Domain Driven Design (DDD) ou la conception pilotée par le domaine
Lors de l’évènement NCrafts 2016, j’ai entendu dans plusieurs conférences auxquelles j’ai participé, l’acronyme DDD et le nom du livre bleu « Domain Driven Design » d’Eric Evans. J’ai donc appris que cette approche de conception était devenue très populaire parmi les craftsmen et j’ai décidé d’écrire un article sur ce sujet.
Ce qu’il faut savoir avant tout, c’est que DDD est un concept et qu’il n’y a rien de technique dedans. Donc ne vous attendez pas à des exemples de code.
Le but de cet article est de vous donner une première idée de ce concept, sa mise en place et son vocabulaire technique.
Objectif
L’objectif de DDD est de créer un langage commun entre différents membres d’une équipe de projet que ce soit technique, fonctionnel, commercial ou autres, afin de faciliter la communication et la compréhension. Une fois ce langage formé, on peut voir le fruit de ce travail dans la partie technique, c’est à dire le code et les tests associés. De cette manière, un développeur, nouveau sur le projet, peut comprendre au fur et à mesure le métier de son client simplement en lisant le code.
Principes
DDD est basé sur deux principes :
- Toute conception métier complexe doit se baser sur un modèle de domaine.
- Se focaliser en premier sur le cœur de métier et sa logique au lieu des contraintes techniques.
Avantages
Ça vous est déjà arrivé de bien étudier un projet, faire de bonnes propositions d’architecture mais d’être obligé de faire plus de modifications que prévues à chaque demande d’évolution du système ? Vous avez probablement travaillé sur un projet complexe au niveau de la logique métier et votre modélisation est basée sur les données à présenter et non sur la logique métier du domaine.
DDD nous apporte des solutions pour stabiliser le système et réduit les coûts de développement dans le cas où le projet est adapté.
D’autre part, il facilite la communication dans l’équipe de projet, facilite l’intégration des nouveaux arrivants et permet la compréhension des sujets complexes du métier.
Utilisation
Comme nous pouvons le constater dans les principes, DDD intervient sur des projets où les concepts métiers sont difficiles à comprendre. Cette approche n’est pas adaptée pour des projets où l’application est focalisée sur l’affichage et l’utilisation des données en ayant peu de logique métier.
Application
En principe DDD est adapté à un langage de programmation orienté objet (POO). La raison est que dans ce type de langage nous pouvons trouver des principes proches de la réalité, comme de l’héritage, et que nous avons des outils qui nous aident à mieux comprendre un métier ou un modèle quelconque. Un langage procédural est plus limité et ne nous offre pas une compréhension réelle du métier qui soit facile à modéliser.
En résumé, dans un langage procédural, le code ne peut pas contenir la logique métier aussi bien que dans un langage orienté objet, ce qui est un des avantages et des forces du DDD.
Communication
La communication est l’élément le plus indispensable dans l’approche DDD.
Imaginez que vous allez participer à une réunion de refonte d’un projet de l’armée.
Dans cette réunion, vous êtes en charge de la partie technique, et êtes accompagné du Product Owner (PO) et du responsable de la base de données.
Le PO commence à parler des BDD et, en tant que développeur, vous pensez de suite à Behaviour Driven Development. Le responsable de base de données pense à une Base De Données mais en réalité le PO parle des Bases De Défense (Zone de responsabilité dans l’armée française). Pour chacun le sujet est si évident qu’il ne pense pas à approfondir le sujet, ce qui est source de confusion et d’incompréhension.
L’approche DDD met donc l’accent sur la communication pour éviter ce genre de problèmes.
Mise en place
En DDD, un projet commence avec plusieurs réunions regroupant différents acteurs qui interviendront directement ou indirectement sur le projet.
Au début, dans ces réunions, nous parlons des généralités et des sujets les plus évidents. Ensuite, plus nous avançons, plus nous nous intéressons à des détails.
Dans ces réunions cycliques, il ne faut pas hésiter à s’interroger et à poser des questions jusqu’à ce que tous les acteurs se mettent d’accord sur une même compréhension et un même vocabulaire.
Dans les premières réunions, nous commençons simplement par prendre des notes en nous écoutant les uns les autres.
La prochaine étape est de relire ses notes et de préparer les questions pour la prochaine réunion.
A la fin, une fois que nous nous sommes mis d’accord sur un « concept », nous pouvons nous exprimer avec des schémas UML, un cahier des charges ou autres.
Cette mise en place peut paraître très lourde et longue, mais il faut savoir qu’une erreur de conception de logiciel est très coûteuse à corriger, plus lourde et plus difficile que cette mise en place.
Compréhension
Il y a quelques outils simples pour mieux comprendre les sujets complexes :
- Des exemples : demander à un acteur du métier de vous citer des exemples
- Des questions : poser des questions sans avoir honte, même si le sujet semble très évident pour les autres membres de l’équipe
- Aller sur le terrain : parfois, se rendre sur place pour voir comment le métier fonctionne en réalité peut beaucoup nous aider à mieux comprendre le sujet
Vocabulaire technique en DDD
Les patterns définis ici ont pour but de séparer les responsabilités techniques dans le code et expliciter les concepts.
Module
Un module regroupe plusieurs services du même domaine. Un module est une interface qui sépare les services dans le but de diminuer les couplages entre eux. Un couplage faible diminue la complexité, et augmente la maintenabilité.
On peut aussi de cette façon modifier et compiler un module sans qu’il n’y ait d’impact sur d’autres modules et sans avoir peur de casser par effet de bord une autre partie du programme.
Service
Un service regroupe les méthodes d’un même domaine. Par exemple, dans un système bancaire, le service de transaction regroupe les transactions d’argent (virement), les transactions d’action (titre et valeur en bourse) etc. Cette couche ne contient pas de logique métier.
Entités
Une entité doit avoir une identité métier unique.
Reprenons l’exemple d’une application bancaire. Imaginez que, pour un virement, nous ayons besoin de l’émetteur, du destinataire et du montant. En DDD, un objet contenant ces trois caractéristiques ne peut pas être une entité, car le domaine qui nous intéresse est une transaction bancaire et non seulement un virement. Il faut donc ajouter dans notre objet un identifiant de transaction pour pouvoir considérer cet objet comme une entité DDD.
Value Objects
Imaginez que vous donniez un billet de 10€ à un ami et qu’il vous donne en échange un autre billet de 10€. Cet échange ne change absolument rien pour vous et votre ami. En DDD, un objet avec ces caractéristiques est appelé un value object.
Les value objects (objets valeurs) sont complémentaires pour une entité. Si nous reprenons l’exemple d’un virement, notre value object est un montant et un devis qui peut être utilisé pour n’importe quel virement.
Les value objects ont donc deux caractéristiques :
- Ils n’ont pas d’identité
- Ils sont partagés entre plusieurs objets métiers
Agrégat
Un agrégat est un objet qui donne l’accès à une entité, ce qui veut dire qu’un service doit passer par un agrégat pour accéder à des valeurs dans une entité.
Dans notre exemple de virement bancaire, le service transaction fait appel à l’agrégat correspondant et, par exemple, vérifie si le solde de l’émetteur est suffisant pour faire le virement. Cette vérification et les autres règles de métier se trouvent dans cet objet agrégat.
Fabrique (Factory)
On utilise les fabriques pour alléger un agrégat quand il commence à contenir trop d’informations.
Dans la vie réelle, c’est comme si on nous donnait un ballon, un terrain, des joueurs, des buts et qu’on construisait notre propre sport. Dans ce cas, on aurait trop d’informations encapsulées au même endroit.
En résumé, les fabriques donnent les informations nécessaires à un agrégat pour le rendre facile à comprendre.
Entrepôt (Repository)
C’est la couche d’accès aux objets de la base de données en DDD.
Cette couche doit être sous forme d’une interface. La raison est qu’une base de données peut changer et cela ne doit pas avoir d’impact sur le domaine et le code associé.
Nous pouvons aussi voir un entrepôt comme un système de cache.
Un entrepôt utilise les fabriques pour restituer des données.
DDD et Agilité
Le domaine métier change souvent et, en conséquence, la modélisation aussi doit changer en faisant du refactoring de code. Cette évolution continue nous oblige à garantir la maintenabilité de l’application et à apporter une maintenance permanente. De plus, DDD met l’accent sur la communication au sein de l’équipe tout comme les méthodologies agiles.
Si vous faites un projet en DDD et que vous utilisez l’agilité, il faut prévoir la présence d’un responsable de domaine qui connaît bien le produit final, et qui est indispensable, au moins au moment du découpage et de l’estimation des tâches techniques. Il est plus préférable et plus logique que le responsable de domaine puisse être présent dans les lieux avec l’équipe de développement, dans le cas où les développeurs ou le chef de projet auraient besoin de l’interroger sur des problématiques métiers.
De plus, toute l’équipe de développement doit participer à la conception du système et pas uniquement l’architecte et le chef de projet.
Conclusion
- DDD est une approche de conception
- DDD nous permet de faciliter la conception
- DDD nous permet de faciliter la compréhension des notions complexes du métier
- La communication est la clé de la réussite d’un projet en DDD
- DDD crée un langage commun entre différents acteurs d’un projet
- DDD et l’agilité sont des approches complémentaires
- DDD facilite l’intégration des nouveaux membres dans l’équipe
- DDD facilite les échanges dans une équipe
- DDD garantit de bien comprendre le besoin du client
- Les tests et TDD sont plus faciles à mettre en œuvre
- Le refactoring et la mise en question des différents concepts doivent se faire de manière régulière
Pour aller plus loin
Je vous conseille de lire les deux livres suivants :
- Domain Driven Design Vite fait par Abel Avram et Floyd Marinescu
- Domain Driven Design par Eric Evans
Sources
- Conception pilotée par le domaine
- Domain Driven Design
- DDD Vite Fait
- Domain Driven Design : des armes pour affronter la complexité
- DDD : la conception qui lie le fonctionnel et le code
- Domain Driven Design, DDD pour les intimes
- Devoxx France 2016 : DDD, et si on reprenait tout depuis le bon bout
- La philosophie du Domain Driven Design
- La conception pilotée par le domaine
© SOAT
Toute reproduction interdite sans autorisation de l’auteur