Domain-Driven Design (DDD) : concevoir des logiciels métier qui parlent le langage de votre entreprise
Obtenez un résumé intelligent et des insights personnalisés
Le Domain-Driven Design (DDD) est aussi appelé conception pilotée par le domaine. C’est une approche de conception logicielle centrée sur le métier. Eric Evans l’a formalisée en 2003. Elle aligne le vocabulaire, le code et les équipes sur les processus réels de l’entreprise. Il convient notamment aux logiciels métier complexes, pas aux applications simples.
Un logiciel métier échoue rarement pour une raison technique. C’est le cas parce que les développeurs et les experts métier ne se comprennent pas. McKinsey et l’Université d’Oxford ont étudié plus de 5 400 projets informatiques dont le budget initial dépasse 15 millions de dollars. En moyenne, ils dépassent leur budget de 45 %. De plus, ils livrent 56 % de valeur en moins que prévu. Le DDD réduit l’écart entre le besoin et le code. Détaillons ensemble son fonctionnement et les cas où il vaut l’investissement. De quoi faciliter le travail de tout dirigeant ou chef de projet qui pilote une application métier.
Qu’est-ce que le Domain-Driven Design et pourquoi change-t-il la conception logicielle ?
Le Domain-Driven Design est une approche qui place le domaine métier au centre de la conception. C’est notamment le champ d’activité de votre entreprise : logistique, assurance, santé ou comptabilité.
Eric Evans a posé ces principes dans Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley, 2003). Deux idées structurent l’approche :
- D’abord, on modélise le métier avec les experts, pas à leur place.
- Ensuite, on isole chaque partie du domaine dans son propre modèle.
Une conception classique part de la base de données ou des écrans. Le DDD part des règles métier. Le code reflète alors le fonctionnement réel de l’entreprise. Quand une règle change, vous la modifiez à un seul endroit. Ce principe s’applique à tout logiciel sur mesure qui porte des règles propres à votre activité.
Comment parler le même langage que les experts métier avec l’ Ubiquitous Language ?
L’Ubiquitous Language est le langage omniprésent. C’est un vocabulaire unique partagé par les développeurs et les experts métier. Il apparaît dans les réunions, la documentation et le code.
Prenons une assurance. Les gestionnaires parlent de « sinistre », les développeurs de « dossier », les juristes de « déclaration ». Trois mots désignent la même chose, et les malentendus naissent là.
L’équipe retient un terme, ici « sinistre », et le définit dans un glossaire. Le développeur nomme ensuite la classe Sinistre. Un expert métier peut alors relire les noms et les règles du code, et repérer une erreur.
Comment découper votre domaine en modules autonomes Bounded Contexts ?
Un Bounded Context est le contexte délimité. Il s’agit notamment de la frontière à l’intérieur de laquelle un modèle et son vocabulaire ont un sens unique (Martin Fowler, 2014).
Le mot « client » illustre le besoin. En facturation, un client possède une adresse de facturation et des conditions de paiement. Au support, il possède un historique de demandes. Ces deux modèles diffèrent, donc vous les séparez en deux contextes.
Chaque contexte devient un module avec son équipe, son modèle et ses règles. Le guide Microsoft sur les microservices .NET recommande de concevoir un modèle de domaine pour chaque microservice ou Bounded Context. Pourtant, un contexte n’impose pas un microservice. Un monolithe modulaire respecte les mêmes frontières, avec une infrastructure plus simple.
Quelles sont les briques de base du Domain-Driven Design : Entités, Value Objects et Agrégats
Le Domain-Driven Design tactique repose sur trois briques (building blocks). Le tableau ci-dessous les définit.
| Brique | Définition | Exemple |
|---|---|---|
| Entité | Objet défini par son identité, qui persiste dans le temps | Commande n° 4521 |
| Value Object (objet-valeur) | Objet défini par ses valeurs, immuable, sans identité propre | Une adresse, un montant en euros |
| Agrégat | Groupe d’objets traité comme un tout cohérent, accessible par une racine | Une commande et ses lignes |
Sources : Eric Evans, Domain-Driven Design (Addison-Wesley, 2003) ; Martin Fowler, « DDD Aggregate », martinfowler.com (2013).
L’agrégat protège la cohérence des règles métier. Vous ne modifiez jamais une ligne de commande directement. Vous passez par la commande, qui vérifie les règles.
Vaughn Vernon recommande des agrégats de petite taille dans Implementing Domain-Driven Design (Addison-Wesley, 2013). Ils réduisent les conflits entre utilisateurs qui modifient les mêmes données.
Lisez aussi notre autre article sur le CQRS et Event Sourcing.
Par où commencer entre le DDD stratégique ou tactique ?
Le DDD stratégique définit la vue d’ensemble : sous-domaines, contextes et langage commun. Le DDD tactique définit le détail du code : entités, objets-valeurs et agrégats.
Nous recommandons de commencer par le stratégique. Vaughn Vernon suit le même ordre dans son ouvrage de 2013. Modéliser finement un contexte mal découpé fait perdre du temps. Voici une séquence de démarrage :
- Identifiez le sous-domaine cœur, celui qui vous différencie de vos concurrents. Evans le nomme « core domain ».
- Définissez les contextes et rédigez un glossaire par contexte.
- Appliquez le DDD tactique au seul sous-domaine cœur.
- Gardez des solutions standard pour les sous-domaines génériques, comme l’authentification ou la facturation.
Comment modéliser votre domaine en atelier collaboratif avec le Event Storming ?
L’Event Storming est un atelier où développeurs et experts métier cartographient un processus sur un mur de post-it. Alberto Brandolini a créé cette méthode.
L’atelier suit quatre étapes :
- Placez les événements métier, écrits au passé, sur des post-it traditionnellement orange. Exemple : « Commande validée ».
- Ajoutez les commandes qui déclenchent ces événements, ainsi que les acteurs concernés.
- Regroupez les événements autour des agrégats.
- Notez les désaccords de vocabulaire. Ils signalent souvent une frontière entre deux contextes.
L’atelier réunit métier et technique dans la même pièce. Il produit un premier langage commun et des contextes candidats.
Quand le DDD est-il pertinent et quand ne l’est-il pas ?
Le Domain-Driven Design est pertinent quand la complexité vient du métier, pas de la technique. Microsoft réserve les patterns DDD aux sous-systèmes complexes et aux règles métier qui évoluent sans cesse.
Le DDD convient dans ces cas :
- Les règles métier sont nombreuses et changent souvent.
- Plusieurs équipes travaillent sur le même logiciel.
- Des experts métier restent disponibles pendant le projet.
- Le logiciel doit durer plusieurs années.
Par contre, le DDD est superflu dans ces cas :
- L’application se limite à de la saisie, dite CRUD (Create, Read, Update, Delete).
- Le produit est un MVP (Minimum Viable Product) destiné à valider une hypothèse.
- Aucun expert métier n’est disponible pour modéliser.
Le DDD demande du temps d’atelier en amont, et ce temps entre dans le budget. Consultez le coût d’un logiciel sur mesure pour situer l’enjeu.
FAQ sur le Domain-Driven Design
Conclusion
Le Domain-Driven Design aligne votre logiciel sur votre métier. Vous obtenez alors :
- Un vocabulaire partagé
- Des modules aux frontières claires
- Et un code que les experts peuvent relire.
Commencez par le DDD stratégique et un atelier d’Event Storming sur votre sous-domaine cœur. Un tel cadrage relève de la gestion de projet informatique.
Pour le mener avec un partenaire technique, découvrez notre agence de développement logiciel sur mesure.
