Sommes-nous passés à côté du Domain-Driven Design ?

le 10/06/2025 par Bruno Boucard

Tags: Software Engineering, Product & Design, Bonne Pratique, Architecture, Delivery

Sommes-nous passés à côté du Domain-Driven Design ?

Le constat

En 2025, les entreprises font face à un constat édifiant, révélateur de la nécessité de repenser en profondeur leurs modes de fonctionnement.

Le pattern d’architecture bien connu du Big Ball of Mud s’impose progressivement comme une pratique répandue dans de nombreuses entreprises.

Dans d'innombrables projets IT, une fracture silencieuse s’installe entre les équipes techniques et les réalités métier. Cette déconnexion, souvent ignorée, finit par coûter cher : perte de sens, gaspillage de ressources, et décisions techniques dénuées de réelle valeur ajoutée.

Les audits se succèdent, aboutissant fréquemment à la même conclusion : tout est à refaire. On pointe du doigt une architecture bancale, un code difficilement maintenable, parfois même incompréhensible.

Aujourd’hui, dans un climat tendu — marqué par une crise économique, une inflation des exigences et une course à la livraison — un certain fatalisme s’installe au sein des équipes IT. Le souci de la qualité logicielle passe au second plan, tandis que des managers, eux-mêmes sous forte pression, en demandent toujours davantage en toujours moins de temps. Les sprints se succèdent, systématiquement surchargés, sans générer de véritable impact métier (Escaping the build trap). Le chaos s’installe.

Et pourtant, les managers ne chôment pas : depuis la crise du COVID-19, les heures supplémentaires sont devenues la règle et, avec la généralisation du télétravail, après une journée au bureau, on se reconnecte dès qu’on a géré ses obligations familiales, tant l’urgence prime, sans véritable reconnaissance ni contrepartie. La peur de l’échec s’est insidieusement imposée comme moteur quotidien : elle contraint les comportements, bride l’initiative et alimente une fatigue à la fois sourde et profonde. Le burn-out, quant à lui, rôde dans l’ombre.

Peu à peu, le poison d’un contexte délétère s’est insinué dans les esprits, rongeant les relations humaines et entamant la confiance individuelle. Les Shadok s'installe pour pomper

Résultat : Un véritable phénomène à la Shadok s’installe : on travaille toujours plus, sans en récolter davantage — ni reconnaissance, ni progrès tangible — et surtout, sans la moindre vision à long terme.

Les relations entre les équipes se sont dégradées. Certains développeurs racontent que l’après-COVID a balayé les fondements de l’agilité, pour laisser place à une logique de commande et contrôle, vidant les collectifs de leur substance.

Dans un contexte de chaos aussi intense, la dimension sociotechnique est complètement négligée : la recherche de solutions prime, au détriment de toute considération humaine.

Inverser la tendance

Préparer le terrain par une communication portée par le management consiste à expliquer en amont le « pourquoi » de chaque action – clarifier le contexte, les enjeux et les bénéfices attendus. Organiser des dialogues croisés permet d’ancrer la réflexion dans la réalité de chacun, et intégrer les suggestions renforce l’empathie et l’adhésion.

Dans un second temps expliquer la démarche à suivre . La “solution” ne réside pas dans une énième méthodologie miracle, mais dans un retour aux fondamentaux :

Recréer un lien fort entre technique et métier, par un dialogue continu, incarné, où les développeurs comprennent les enjeux business et où les métiers redécouvrent la réalité technique.
Redonner de l’autonomie aux équipes, en recréant un cadre de confiance, de responsabilité partagée, et en s’attaquant aux racines du mal : surcharge, flou des priorités, dette technique ignorée.
Remettre du sens dans la production logicielle, en valorisant l’impact plutôt que la vélocité, la qualité plutôt que la quantité.

Il ne s’agit pas d’aller plus vite. Il s’agit d’avancer mieux. De bâtir un collectif durable, aligné sur une vision claire, où chaque membre trouve sa place, sa voix, et sa motivation.

La sérénité et le temps sont les conditions sine qua non pour comprendre en profondeur les problématiques soulevées, sans succomber à la tentation de solutions toutes faites qui ne font souvent qu’aggraver le désastre logiciel.

Or, la course effrénée aux fonctionnalités, les incidents en production et la pression hiérarchique créent un engrenage dont il est difficile de se dégager. Changer ses habitudes demeure l’une des épreuves les plus ardues. Comme le rappelait Jean Monnet : « Les hommes n’acceptent le changement que dans la nécessité, et ils ne voient la nécessité que dans la crise. » Face à l’adversité, seul un véritable changement de posture permet de progresser : prendre le temps de mûrir ses réflexions et de les partager est un remède éprouvé pour gagner en recul.

Enfin, il ne faut surtout pas négliger le rôle essentiel du sommeil dans cette digestion mentale : il faut « dormir dessus » pour y voir plus clair, tant au sens propre qu’au figuré. Adopter un mode de travail durable et soutenable apparaît alors comme la discipline fondamentale pour enclencher une amélioration réelle et pérenne, retrouver la sérénité et disposer du temps nécessaire à l’analyse approfondie des enjeux.

Qui, après ces explications, pourrait encore penser qu’une demande métier complexe se limite à traduire un besoin en code ?

C’est aussi un effort collectif. Cela implique de clarifier, de challenger les idées reçues, de creuser ensemble jusqu’à faire émerger une représentation simplifiée d’un concept, d’un phénomène, d’une réalité métier.

Une bonne modélisation met intentionnellement en avant certains aspects, tout en en ignorant d’autres — non pas par négligence, mais par choix, en fonction de la valeur que l’on souhaite créer.

Car modéliser, c’est aussi renoncer à la complexité inutile, à l’ambiguïté, à l’automatisme de “ce qu’on a toujours fait”.

Mais qu’est qu’un modèle métier ?

Un modèle métier est une représentation simplifiée de la réalité, élaborée dans un but précis : comprendre, expliquer, prédire ou agir sur un phénomène complexe. Il met en lumière certains aspects jugés pertinents tout en laissant volontairement de côté d’autres éléments, considérés comme secondaires dans le contexte donné.

Plutôt que de s’interroger sur la véracité absolue d’un modèle, il est souvent plus judicieux de se demander s’il est utile ou applicable dans un contexte précis. Un bon modèle n’est donc pas celui qui prétend embrasser toute la complexité du réel, mais celui qui facilite l’action, la prise de décision ou la compréhension d’un problème donné.

Comme le disait le statisticien George Box :

Tous les modèles sont faux, mais certains sont utiles.

C’est à cet instant qu’intervient le Domain-Driven Design (DDD). Non comme une méthode miracle, mais comme un cadre de pensée pour reconnecter les équipes techniques des experts métier réunis autour d’un langage commun et d’une compréhension partagée, au sein d’équipes pilotées par la modélisation et ancrées dans une complexité métier porteuse de sens. Grâce à l’approche DDD, la modélisation s’intègre naturellement : chaque équipe agit de manière autonome tout en restant alignée avec sa raison d’être fonctionnelle.

Et si nous étions passés à côté du Domain-Driven Design (DDD) ?

Introduit par Eric Evans en 2003, le Domain-Driven Design (DDD) est une approche de conception logicielle qui place le domaine métier au cœur du processus de développement. Son objectif est de comprendre en profondeur l’activité métier pour structurer le code de manière cohérente avec cette compréhension.

Dans un contexte où le sens des projets IT se dilue souvent dans la complexité technique, je vous invite à explorer le Domain-Driven Design à travers cinq grandes étapes didactiques, ponctuées d’ateliers collaboratifs.

Découpage du domaine en sous-domaines
Cartographie des relations entre les bounded contexts
Modélisation détaillée du bounded context core
Modélisation collaborative de l’agrégat
Modélisation collaborative au niveau du code appellé le Model-Driven Design

Découvrez comment cette approche rétablit une vision commune entre experts métier et équipes techniques, pour concevoir des solutions porteuses de sens, incarnées par une base de code à la fois maintenable, durable et évolutive.

Expliquer le Domain-Driven Design de manière simple et didactique reste un exercice délicat. Pour éviter d'ajouter des étapes supplémentaires, j'ai volontairement omis l'utilisation des terminologies stratégique (logique/organisationnelle) et tactique (physique/code). Néanmoins, la décomposition proposée permet de mieux appréhender la démarche globale, en réponse au constat formulé en introduction.

Explorer un domaine métier afin de le comprendre

La phase d’exploration du domaine métier est une étape clé : elle constitue le point de départ du découpage en sous-domaines, qui guide ensuite la structuration des équipes métier et la définition de leurs interactions. Ce n’est qu’une fois ces fondations posées que l’on peut s’intéresser, de manière pertinente, à la modélisation du code — pas avant.

Pour analyser un domaine métier complexe, il convient de réunir des profils variés — utilisateurs, experts métier, product managers et équipes IT — pour recueillir et valider, au cours de conversations concrètes, des récits d’activités. Regroupés par rapprochement fonctionnel au fil d’itérations successives, ces récits font émerger les sous-domaines fonctionnels qui structurent le système d’information dans un état actuel, ou cible ou bien encore exploratoire.

Dans cette perspective, le Domain-Driven Design (DDD) recommande de cartographier ces sous-domaines pour mieux comprendre la décomposition fonctionnelle du métier et établir une organisation du système d’information reflétant tant l’état actuel que la cible plus cohérente. L'un des outils clés pour y parvenir est l'atelier collaboratif Big Picture Event Storming, une méthode visuelle et participative conçue par Alberto Brandolini, qui permet de représenter l'ensemble des processus métier de manière globale et partagée.

La diversité des participants facilite une confrontation efficace des points de vue.

Lors d’un Event Storming Big Picture, les participants se répartissent en petits groupes selon leurs affinités fonctionnelles, afin de co-construire des récits conformes à leur domaine d’expertise. Ces sous-groupes deviennent les artisans de la frise visuelle, qui prend forme de façon progressive et spectaculaire.

La dimension spatiale de l’Event Storming permet de visualiser l’évolution au fil du temps.

Les participants se répartissent en fonction de leur expertise métier afin de décrire, à l’aide d’événements métier, des récits (ou "narratives") illustrant les comportements et enchaînements fonctionnels liés à l’activité étudiée. Ces récits sont organisés chronologiquement, de gauche à droite, pour représenter le déroulement des processus dans le temps.

Big Picture Event Storming : une exploration visuelle collaborative

Exemple d’un récit, c’est-à-dire une suite d’événements métier.

La décomposition d'un processus en évènements simples permet d'obtenir un récit clair et détaillé

Méthode de brainstorming visuel mobilisant des participants aux profils variés, à la fois techniques et métiers.
Chaque participant identifie des événements marquants liés à son activité, qu’il formule au participe passé sur des post-its orange.
L’objectif : faire émerger une vision globale, partagée et intelligible du domaine exploré.
Des post-its rose-néons, appelés hotspots, permettent de mettre en évidence des zones d’ombre ou des sujets encore peu explorés.
L’enjeu n’est pas de tout résoudre immédiatement, mais de reconnaître les problématiques pour amorcer une compréhension commune..

Structuration des événements

Une phase de rationalisation organise les événements de façon chronologique pour créer des récits métier cohérents.
Ces récits sont ensuite segmentés pour identifier les sous-domaines métiers.

Conditions de réussite d’un Event Storming Big Picture

La diversité des participants est un facteur clé de succès. Il est essentiel que chacun dispose d’une compréhension suffisante du domaine exploré. Des connaissances trop partielles peuvent conduire à des récits incomplets et à une modélisation appauvrie. Dans ce cas, il est judicieux d’impliquer des profils complémentaires, capables d’apporter les perspectives manquantes.

De plus, l’énergie collective est essentielle à la bonne dynamique de l’atelier. Si le groupe est fatigué ou peu engagé, il produit peu d’événements et reste sous l’influence des animateurs, ce qui n’est pas une orientation favorable pour la suite de l’Event Storming.

Classification stratégique des sous-domaines

Une fois les sous-domaines identifiés, ils sont classés à l’aide du Core Domain Chart :

Core Domain : sous-domaines stratégiques apportant un avantage concurrentiel.
Supporting Domain : domaines nécessaires, liées à l’activité du Core Domain.
Generic Domain : domaines standards pouvant être couverts par des solutions génériques ou existantes.

Mise en correspondance des sous-domaines logiques avec des Bounded Contexts physiques.

La projection des sous-domaines métier en Bounded Context est une phase clef de l’Event Storming Big Picture

Dans cette projection, on constate qu’un même sous-domaine peut donner lieu à deux Bounded Contexts. Cela est tout à fait acceptable, car la charge cognitive liée aux activités de ce sous-domaine est trop élevée pour une seule équipe.

Pour illustrer concrètement le mécanisme de projection dans le cadre de la réservation de billets de train, nous nous sommes focalisés sur trois contextes essentiels, en écartant la facturation et l’émission des billets afin de gagner en clarté.

Illustration du découpage en sous-domaines dans le contexte de la réservation de sièges de train.

Dans le domaine de la réservation de tickets de train, on à projeter les sous domaine en bounded context spécifiques

Cette classification guide la mise en place d’équipes alignées sur les spécificités de chaque sous-domaine.

Existe-t-il une hiérarchie entre l'équipe core, les équipes support et les équipes génériques ?

Il n'existe pas réellement de hiérarchie formelle entre ces différentes types d’équipes. Toutefois, l'équipe core est naturellement soumise à davantage de pression, car son impact sur le produit est central et décisif. Les équipes support, quant à elles, jouent un rôle essentiel en accompagnant et en renforçant le travail de l’équipe core, contribuant ainsi directement à son succès.

Le cas des équipes génériques est plus nuancé : bien qu’elles n’apportent pas de valeur différenciante et puissent parfois être remplacées par des solutions « sur étagère », leur rôle reste fondamental. Sans elles, le produit ne peut tout simplement pas fonctionner.

Bounded Context et cartographie des interactions

Chaque sous-domaine est décliné en un ou plusieurs Bounded Context si besoin, c’est-à-dire un périmètre métier clairement défini au sein duquel une équipe structure sa solution.

Pour comprendre les interactions entre ces contextes, le DDD utilise la cartographie des contextes (Context Mapping), qui permet d’analyser les relations et dépendances entre Bounded Contexts.

Les apports du Context Mapping

Les Context Maps décrivent les interactions entre les bounded contexts à travers une collection de patterns.

La bonne santé de l’organisation dépend de l'équilibre des relations de pouvoir entre les Bounded Contexts.

Ces patterns offrent plusieurs angles d’analyse — fourniture de services, propagation de modèles, ou encore aspects de gouvernance — permettant d’appréhender les relations entre bounded context de manière holistique.

Les contextes map sont utiles aussi bien pour analyser des systèmes ou des paysages applicatifs existants que pour accompagner les réflexions en phase de conception initiale.

Domain-Driven Design et Team Topologies au service de la qualité logicielle et de la performance organisationnelle.

À ce stade, afin de renforcer notre capacité à délivrer plus rapidement de la valeur métier, il peut être pertinent d'explorer l’approche Team Topologies.

Cette approche propose un cadre structuré pour organiser les équipes au sein d’une entreprise, en clarifiant leurs responsabilités, leurs modes d’interaction et leurs canaux de communication.

Conçue pour s’ajuster à de nombreuses structures, Team Topologies s’avère bien plus adaptée aux environnements logiciels qu’au secteur industriel.Elle permet de modéliser la structure des équipes en tenant compte à la fois des contraintes de collaboration et de la complexité du domaine métier.

Son objectif principal est d’accélérer le flux de changement, en s’appuyant sur des principes modernes d’ingénierie et de delivery continue.

Le Domain-Driven Design et l’approche Team Topologies sont largement complémentaires.
Les experts DDD et les équipes de facilitation poursuivent des objectifs similaires : réduire la charge cognitive des équipes et favoriser leur montée en compétences. Toutefois, leurs périmètres d’intervention et leurs leviers stratégiques diffèrent.

Design organisationnel du Domain-Driven Design

L’approche DDD s’articule autour d’un découpage métier fondé sur une sémantique profonde. Les experts DDD se focalisent sur une compréhension approfondie du domaine et sur la conception de modèles conceptuels cohérents, directement alignés avec les besoins métier.

Design organisationnel de Team Topologies

Team Topologies s’inscrit dans une dynamique de vélocité globale afin de garantir la livraison continue de valeur métier. Les équipes de facilitation issues de cette démarche interviennent de manière transverse sur les enjeux techniques, organisationnels et méthodologiques. Leur mission est d’optimiser la collaboration et de fluidifier les livraisons à l’échelle de l’organisation en comblant les points de friction relationnels.

Dans un prochain article, j’aborderai la complémentarité entre Team Topologies et Domain-Driven Design en profondeur.

Une fois cette étape accomplie, il s’agit de passer d’une organisation principalement logique à une mise en œuvre tangible, où l’ensemble des ressources — collaborateurs, documents, communications, dépôts et artefacts de code — sont alignés et structurés autour de la notion de Bounded Contexts.

Nous entrons à présent dans des aspects plus concrets et opérationnels, au sein d’une organisation structurée autour de la modélisation. La phase exploratoire a permis de prendre du recul, d’acquérir une vue d’ensemble du domaine métier et de définir un découpage en sous-domaines, donnant ainsi naissance à une organisation tangible. L’attention se porte désormais sur les activités de l’équipe core, en particulier sur le Bounded Context principal.

Le Bounded Context : une frontière pour structurer la complexité

Un Bounded Context est une frontière logique à l’intérieur de laquelle un modèle métier cohérent et sans ambiguïté s’applique. Il correspond au périmètre d’une équipe ou un système externe.

Ce découpage permet de :

Clarifier la sémantique métier et d’éviter les confusions,
Modéliser avec précision les règles, responsabilités et comportements,
Concevoir et faire évoluer et maintenir le service métier de manière autonome.

Le Bounded Context désigne une sphère de connaissances métier clairement délimitée, formant une unité cohérente sur le plan fonctionnel. À l’intérieur de ce périmètre, un vocabulaire commun et partagé est utilisé par l’ensemble des acteurs — experts métier, parties prenantes, architectes logiciels et équipes de développement — pour concevoir une solution répondant à un problème métier spécifique. Cette organisation favorise une compréhension claire des besoins et permet une modélisation du code plus précise, même dans des environnements complexes.

L’autonomie, sans compromis, est la pierre angulaire des bounded contexts

Le Bounded Context constitue un cadre idéal pour modéliser un sous-domaine métier complexe de manière autonome. Il s'agit d’un principe fondamental du Domain-Driven Design, applicable à tous les niveaux d’une architecture. Cette autonomie, sans compromis sur la cohérence ou la qualité, permet à l’organisation de gagner en agilité, de fonctionner de façon plus dynamique et de délivrer davantage de valeur, en limitant les dépendances externes.

Un langage commun pour mieux se comprendre

Le langage ubiquitaire est un concept fondamental du Domain-Driven Design (DDD). Il s’agit d’un langage commun, partagé entre les développeurs et les experts métier, qui sert à décrire clairement les règles, les comportements et les concepts pour un sous-domaine métier donné.

Son rôle est de faciliter la compréhension mutuelle, d’éviter les malentendus et de rendre la modélisation plus fluide. Grâce à ce langage, tout le monde parle des mêmes choses, avec les mêmes mots, dans un cadre précis appelé Bounded Context.
Ce langage n’est pas figé. Il évolue avec le temps, au fil des discussions, des découvertes et de l’affinement du modèle. On part souvent d’un vocabulaire simple, parfois maladroit, pour arriver progressivement à un langage plus précis, plus riche, et mieux adapté à la réalité du métier.
À terme, ce langage se reflète aussi dans le code, ce qui le rend plus clair, plus compréhensible, et plus facile à faire évoluer. C’est ainsi que le langage ubiquitaire devient un véritable outil de collaboration, de conception et de qualité logicielle.

Les deux niveaux du langage ubiquitaire

Le langage ubiquitaire se décline en deux niveaux, chacun jouant un rôle complémentaire dans la modélisation :

Le langage ubiquitaire est propre à un Bounded Context. Il permet d’exprimer avec précision les subtilités du métier et de modéliser des concepts complexes de façon fine et contextualisée.
Le langage ubiquitaire de “surface”, quant à lui, est utilisé en dehors de ce contexte précis. Il fournit une vue plus générale et simplifiée, utile pour communiquer avec des interlocuteurs extérieurs ou coordonner plusieurs équipes.

Cette distinction structure les échanges et évite les confusions liées aux différents niveaux de compréhension entre contextes métiers. Le langage ubiquitaire “de surface” permet une communication explicite et efficace à un niveau général, tandis que le langage ubiquitaire renforce la collaboration entre les acteurs et offre une gestion plus maîtrisée de la complexité au sein d’un même contexte métier.

Dans cette perspective, le langage ubiquitaire constitue un levier fondamental du Model-Driven Design, en ancrant les modèles dans une sémantique claire, partagée et pleinement intégrée. Une fois assimilé par l’équipe de développement, il favorise des échanges fluides et bidirectionnels avec les experts métier. Les impacts sur la modélisation du problème sont majeurs : le code devient le reflet d’une sémantique fonctionnelle forte.

Event Storming – Software Design - Modéliser les comportements métier avec précision

Event Storming Software Design pourquoi faire ?

Une fois la topologie des équipes établie et les affinités d’impact (core, supporting et générique) sur le segment de marché du produit identifiées, il est temps d’aborder la complexité du Bounded Context Core. Cette phase, délicate, vise à affiner nos opérations à un niveau de granularité plus fin afin de satisfaire précisément les besoins exprimés, tout en concevant un modèle à la fois robuste, souple, maintenable et évolutif.

À l’image de l’Event Storming Big Picture, l’Event Software Design s’appuie certes sur les événements métier (sticker orange), mais ne s’y limite pas : il bénéficie d’une grammaire étendue, offrant une plus grande liberté d’expression.

L’Event Storming – Software Design est un atelier collaboratif collaboratif puissant pour concevoir des systèmes logiciels complexes, en assurant un alignement étroit entre les besoins métier et les choix techniques au sein d’un Bounded Context Core.

Il s’agit d’un Event Storming à audience bien plus restreinte que celle du Big Picture, où les échanges entre les participants s’appuient sur le langage ubiquitaire de l’équipe. La précision et la rapidité de ces interactions sont totalement différentes de celles du Big Picture. Cette expérience, propre à l’équipe, vise à développer une modélisation approfondie en adoptant l’approche Model-Driven Design que nous détaillerons prochainement.

Conçue pour une audience mixte — experts métier et équipe de développement — cette approche facilite la compréhension fine des usages du système. Elle repose sur une modélisation centrée sur les comportements métier, structurée autour d’une sémantique claire et partagée.

L’Event Storming Software Design permet de modéliser en détail les comportements métier, en particulier au sein des équipes en charge du core domain.

Cette approche s’appuie sur une sémantique riche, en mobilisant l’ensemble des éléments du langage visuel propre à l’Event Storming.

Dans l’Event Storming Software Design, les couleurs sémantiques sont utilisées pour représenter les différents composants du système avec précision :

Orange : événements du domaine
Bleu : commandes ou ordre (intentions ou actions déclenchées par les utilisateurs ou le système)
Jaune: agrégats (entités ou groupes d’entités qui maintiennent leur cohérence)
Violet: politiques ou règles métier (processus décisionnels, sagas, etc.)
Rose : systèmes externes (intégrations, API tierces, services externes)
Vert : modèles de lecture (read models, vues optimisées pour les requêtes)
Blanc : interface utilisateur

On distingue deux formats de post-its, les carrés pour véhiculer l’information et les rectangles pour réceptionner et émettre de l’information. Par exemple, un système externe reçoit une commande et émet un évènement métier, comme l’agrégat. Contrairement à la Policy (politique ou règles métier) qui reçoit un événement métier et qui émet une commande.

En combinant ces éléments, les équipes peuvent explorer finement les flux métier, comprendre les interactions entre composants, et construire une base solide pour un design aligné sur les besoins réels du domaine.

Grâce à l’utilisation du langage ubiquitaire, les flux métier sont visualisés avec une grande précision. Cette représentation riche améliore la compréhension collective, garantit une modélisation fidèle à la réalité du domaine et facilite la maintenance du système dans le temps.

Pourquoi structurer le code en agrégats ?

L’objectif de l’Event Storming Software Design est de détailler le fonctionnement interne d’un service ou d’une application. Le sticker jaune symbolise le cœur du logiciel : il contient la substance la plus précieuse, à savoir la modélisation métier du problème spécifique, avec l’ensemble des comportements métier associés. Cette étape est à la fois délicate et cruciale.

Dans les modèles comportant de nombreuses associations entre objets, il devient difficile de garantir la cohérence globale. Chaque objet est censé maintenir son propre état, mais des modifications sur des objets liés peuvent compromettre cette cohérence.

L’utilisation d’agrégats permet de définir des frontières claires autour d’un ensemble d’objets cohérents. Cela facilite la maîtrise des règles métier, réduit les dépendances, et protège l’intégrité du modèle.

Par ailleurs, les verrouillages trop prudents en base de données peuvent provoquer des interférences inutiles entre utilisateurs, impactant négativement l’expérience et la performance du système.

Ces défis sont encore plus marqués dans des contextes d’architectures distribuées ou de transactions asynchrones, où la gestion fine de la cohérence devient critique. Structurer le code en agrégats permet d’adopter une approche plus robuste, mieux adaptée à ces environnements.

Comment structurer le code en agrégats ?

Pour structurer le code autour des agrégats, commencez par regrouper les entités et objets-valeurs qui forment un ensemble cohérent autour d’une entité racine. Cette racine est le point d’entrée unique de l’agrégat, responsable de faire respecter les règles métier internes.

Ensuite, identifiez les invariants métier (règles qui doivent toujours être vraies) que l’agrégat doit garantir. Ces règles sont appliquées de manière synchrone à l’intérieur de l’agrégat, tandis que les interactions entre agrégats peuvent être gérées de manière asynchrone (par événements, messages, etc.).

Les frontières de l’agrégat servent également à délimiter les transactions et à gérer la distribution du système. Chaque agrégat doit idéalement être hébergé sur un seul serveur, pour préserver sa cohérence et éviter les complexités de synchronisation distribuée.

Enfin, si la structure choisie ne répond plus bien aux besoins, cela peut être le signal d’une évolution dans la compréhension du domaine. Réévaluer le modèle à ce moment-là permet souvent de gagner en flexibilité, en robustesse et en pertinence métier.

Débuter la modélisation de l’agrégat

Modéliser un agrégat est une tâche exigeante : elle consiste à organiser un ensemble d’entités et de règles en un tout cohérent, capable de faire respecter les invariants métiers.

Pour faciliter cette activité, deux types d’ateliers collaboratifs sont particulièrement efficaces :

Example Mapping : il permet d’explorer les règles métier à partir d’exemples concrets. Cette approche favorise une compréhension partagée des invariants et clarifie les cas d’usage réels.

L’atelier Example Mapping nous vient de la phase exploratoire du Behavior-Driven Development (BDD)

CRC Cards (Class–Responsibility–Collaborator) : elles aident à structurer l’agrégat en identifiant ses entités, leurs responsabilités et leurs interactions, dans une dynamique de modélisation collective.

L’atelier CRC Cards Inventé en 1989 par Kent Beck et Ward Cunningham pour faciliter la conception orientée objet.

Ces pratiques encouragent l’alignement fonctionnel entre les experts métier et les développeurs. Elles offrent ainsi une base solide pour produire un code à la fois fidèle à la réalité métier, robuste, et cohérent avec la vision d’ensemble du système.

Une fois que l’équipe a travaillé ensemble pour définir clairement le fonctionnement de l’ensemble, elle peut commencer à créer le code correspondant.

Les CRC Cards appliquées à la modélisation de notre agrégat racine .

Ajout des règles métier issu de l’Example Mapping

Projeter les invariants (règle métier) de l’Example Mapping afin de compléter la modélisation.

À ce moment-là, la façon de voir l’agrégat devient plus technique et commence à refléter plus clairement les éléments concrets qui composent le système.

La modélisation du code : cœur du Model-Driven Design

L’objectif ultime du Domain-Driven Design est de faire émerger un code qui reflète fidèlement le domaine métier.

Cette approche, appelée Model-Driven Design, repose sur trois piliers tactiques complémentaires :

Building Blocks constitue une boîte à outils de patterns fondamentaux — entités, agrégats, objets-valeurs, services, etc. — permettant d’organiser le code de manière claire, cohérente et centrée sur le métier.
Deep Modeling désigne un processus de modélisation collaboratif, itératif et exploratoire, au cours duquel l’équipe technique et les experts métier affinent ensemble les concepts clés jusqu’à en dégager l’essence.
Enfin, Supple Design regroupe un ensemble de patterns de conception visant à produire un code souple, expressif, maintenable et capable d’évoluer sans rigidité, même dans un contexte de changement constant des besoins métier.

En combinant ces trois dimensions, le Model-Driven Design permet d’écrire un code aligné sur la réalité métier, tout en restant robuste et adaptable.

Le Model-Driven Design pour quoi faire ?

Le concept de Bounded Context constitue un écrin de modélisation fine pour les équipes : il prend tout son sens lorsqu’il offre un espace privilégié de réflexion approfondie, où le langage ubiquitaire s’invite à chaque instant. Plongées dans cette sphère de connaissances, les équipes exploitent le Model-driven Design à travers des outils (building blocks), des patterns (principes du Supple Design) et une approche spécifique (Deep Modeling) pour produire un code à la fois simple, propre, robuste, maintenable et évolutif.

Les Building Blocks des patterns fondamentaux pour structurer le code

Les Building Blocks pourquoi faire ?

Une méthode traditionnelle pour introduire l’analyse orientée objet consiste à repérer les noms et les verbes dans les documents de spécification, en les traduisant respectivement en objets et en méthodes.

Si cette approche peut s’avérer utile à des fins pédagogiques — notamment pour initier les débutants à la modélisation objet — elle reste une simplification excessive.

Dans la pratique, les premiers modèles issus de cette méthode sont souvent naïfs et superficiels, car ils reposent sur une compréhension encore limitée du domaine. Ils reflètent rarement la complexité réelle des règles métier et nécessitent d’être enrichis, structurés et challengés pour aboutir à une modélisation pertinente et durable.

Les building blocks structurent le code en lui apportant une urbanisation cohérente, qu’il convient ensuite de compléter par la modélisation des comportements et des règles métier. Ils soutiennent la démarche de modélisation sans pour autant la fournir.

Building Blocks structurent le code de manière cohérente et maintenable

Les Building Blocks sont un ensemble de patterns récurrents conçus pour structurer le code de manière claire, cohérente et maintenable. Ils offrent un cadre pragmatique, composé d’éléments simples mais puissants, facilitant ainsi le développement et posant les bases d’une architecture logicielle robuste.

Cependant, bien qu’ils constituent des solutions prêtes à l’emploi, leur utilisation nécessite du discernement. Chaque Building Block répond à une intention précise et doit s’inscrire naturellement dans votre design. S’il ne correspond pas à un besoin réel, il est préférable de ne pas l’intégrer.

Afin de les passer en revue rapidement, je vous propose un exemple de code qui vous présente un service de réservation pour une compagnie ferroviaire. Vous retrouverez les building blocks suivants:

Service - Lorsqu’un processus ou une transformation significative du domaine ne relève pas naturellement de la responsabilité d’une entité ou d’un objet-valeur, ajoutez une opération au modèle sous la forme d’une interface autonome, déclarée comme un service
Repository - Regrouper dans un adaptateur l’accès à aux données, mais les requêtes à celui-ci doivent être exprimées dans le langage ubiquitaire pour éviter de compliquer le modèle.
Value Object - Certains objets décrivent ou calculent des caractéristiques, mais n’ont pas d’identité conceptuelle.
Aggregate - Garantir la cohérence des objets dans un modèle avec des associations complexes est difficile, le Building Block Aggregate, est une solution.
Domain Event - Il s'est produit quelque chose qui intéresse les experts du domaine.

Voici un exemple concret de ce que présenté un service exprimé avec quelques Building Blocks

Sur ce fragment de code, presque tous les building blocks sont présents

Cependant, leur portée reste limitée à une modélisation essentiellement structurelle. L’exploration en profondeur des concepts métier, leur compréhension fine et leur formalisation rigoureuse relèvent de la modélisation profonde (Deep Modeling), une approche itérative centrée sur l’essence du domaine métier.

Le Supple Design et ses patterns de code

Le Supple Design pourquoi faire ?

Le Supple Design insuffle une élégance expressive et une souplesse maîtrisée dans la gestion de l’immutabilité et de l’autonomie. Ces patterns incarnent une esthétique apaisante, qui dissipe angles morts et incohérences comportementales. C’est grâce au Supple Design que s’élabore une réflexion plus profonde, ouvrant la voie à un modèle à la fois simple, efficace, maintenable, évolutif et, surtout, robuste.

Concrètement le Supple Design c’est quoi ?

Le Supple Design désigne un ensemble de patterns visant à rendre le code à la fois flexible et résilient, en facilitant les évolutions fréquentes propres à l’approche de Deep Modeling.

Ces patterns privilégient une définition précise des responsabilités, encouragent l’indépendance des classes et favorisent leur immuabilité. L’objectif est de construire une structure de code souple mais solide, capable de s’adapter sans fragiliser l’ensemble du système.

En s’inscrivant pleinement dans l’approche du Deep Modeling, les patterns du Supple Design accompagnent les équipes dans l’exploration progressive et l’éclaircissement des problématiques métier. Itération après itération, ils permettent d’affiner la modélisation de manière continue, tout en garantissant cohérence et efficacité.

Le Supple Design a pour objectif la conception d’un modèle métier fluide, expressif et évolutif, en assurant un alignement étroit entre le code et la réalité du domaine. Il permet un refactoring continu, indispensable pour affiner la modélisation au fil des itérations, et repose sur quatre qualités fondamentales :

Lisibilité un modèle clair, accessible et compréhensible, y compris pour les non-techniciens ;
Expressivité un code qui reflète fidèlement les concepts métier et en facilite la compréhension ;
Souplesse la capacité d’intégrer de nouvelles règles ou évolutions sans remettre en cause l’existant ;
Cohérence des éléments du modèle qui interagissent de manière fluide, logique et prévisible.

En résumé, le Supple Design favorise une modélisation plus profonde, un code plus explicite fonctionnellement et un système plus résilient face au changement.

Deep Modeling – Un refactoring guidé par la compréhension métier

Le Deep Modeling pourquoi faire ?

Les Building Blocks posent la structure, et le Supple Design en affine la forme avec élégance et souplesse. Mais maintenant que le cadre est établi, il est temps d’engager une modélisation plus approfondie, où la naïveté n’a pas sa place. Nous travaillons main dans la main avec notre expert métier pour esquisser, sur le paperboard, les règles en action dans notre modèle. Les questions fusent, l’expert répond, prend le temps de réfléchir puis revient avec de nouvelles idées auxquelles l’équipe adhère unanimement ; parfois même, le rapport s’inverse et c’est l’équipe de développement qui dirige la conversation. Au fil du temps, le modèle s’enrichit de raffinements subtils du code, permettant d’aborder avec simplicité ce qui, au départ, paraissait d’une complexité incroyable.

Concrètement le Deep Modeling c’est quoi ?

Il s’agit d’une réflexion approfondie au service du modèle métier : un défi intellectuel qui ne repose pas sur une seule personne, mais mobilise à la fois l’équipe de développement et l’expert métier ; c’est là toute la force de ce dispositif de réflexion profonde.

Le Deep Modeling repose sur un refactoring orienté vers une compréhension approfondie du domaine métier, piloté par des experts tels que le Product Owner ou le Business Analyst.

Contrairement au refactoring classique tel que défini par Martin Fowler — centré sur des améliorations techniques sans changement de comportement — cette approche privilégie un raffinement itératif du modèle, rendu possible grâce aux patterns du Supple Design.

Les concepts métier complexes sont explorés et clarifiés à travers des scénarios concrets, souvent intégrés dans un prototype. Cette démarche réduit l’influence du code existant sur les choix de conception, en permettant une prise de recul stratégique.

Chaque composant du système est alors réévalué : il peut être simplifié, transformé ou éliminé s’il ne répond plus à un besoin métier identifié. Le résultat est une base de code plus explicite, cohérente et alignée sur la réalité du domaine.

Rendre explicites les concepts implicites

Un modèle profond vise à capturer, de manière concise et structurée, les concepts centraux et les connaissances essentielles du domaine. Il commence par une représentation initiale des éléments clés, puis s’enrichit progressivement par un travail de knowledge crunching et de refactoring.

Le processus gagne en intensité lorsqu’un concept important, jusque-là implicite ou diffus dans les discussions, est identifié puis formalisé dans le modèle. Ce travail de clarification se traduit souvent par la création d’objets, de relations ou de structures reflétant explicitement ce concept.

Ainsi, de nombreuses évolutions du modèle de domaine et du code émergent de cette démarche d’explicitation, permettant une meilleure compréhension, une plus grande expressivité et une modélisation plus fidèle du métier.

Ne vous laissez pas paralyser en tentant de provoquer une percée majeure. Ces percées surviennent généralement après de nombreux refactorings modestes. La majeure partie du temps est consacrée à des améliorations progressives, les idées liées au modèle émergent petit à petit à chaque itération.

Breakthrough – Le pouvoir des percées conceptuelles

Si le refactoring est généralement progressif et incrémental, il ouvre la voie à des percées majeures dans la compréhension du domaine.

Chaque petit ajustement contribue à améliorer la clarté du modèle et du code, réduisant l’entropie et posant les bases d’une structure plus solide.

Cette clarté nouvellement acquise peut alors déclencher des révélations décisives : des idées qui permettent de réaligner en profondeur le modèle sur les véritables priorités des utilisateurs. Le résultat est un modèle à la fois plus simple et plus puissant, dont la capacité explicative est renforcée sans accroître la complexité.

Refactoring Toward Deeper Insight – Refactorer pour mieux comprendre

Le refactoring orienté vers une compréhension approfondie du domaine repose sur trois piliers essentiels :

Vivre dans le domaine - s’immerger dans le contexte métier réel, au plus près des utilisateurs ;
Explorer différentes perspectives - croiser les points de vue techniques et métier pour enrichir la modélisation ;
Maintenir un dialogue continu - collaborer étroitement et régulièrement avec les experts du domaine.

Bien que le refactoring classique — visant à améliorer le code sans en modifier le comportement — reste important, il doit s’inscrire dans une démarche plus large : celle d’une meilleure compréhension du domaine.

Ce type de refactoring débute souvent par l’identification d’un dysfonctionnement dans le modèle — concept manquant, relation inexacte, incohérence subtile — même si le code fonctionne techniquement. Il peut également émerger d’un apprentissage progressif ou d’une opportunité de simplification.

Une fois le besoin de clarification détecté, une équipe d’exploration (composée de développeurs et, idéalement, d’experts métier) se réunit pour confronter les idées, tester des pistes et affiner ensemble le modèle.

Cette démarche collective permet de faire émerger des représentations plus justes, plus expressives et mieux alignées sur la réalité du métier.

Synthèse de l’approche Domain-Driven Design

L’objectif est de mettre en lumière l’effet d’entonnoir de l’approche : partir d’une granularité large, impliquant une audience issue du domaine métier, pour progressivement converger vers une granularité fine, centrée sur une équipe de développement.

Depuis l’organisation d’un domaine métier à la modélisation d’un Bounded Context Core.

Mon propos suit un fil linéaire pour des raisons pédagogiques.

Cependant, la réalité est souvent plus complexe. Il est tout à fait possible – et même recommandé – de passer d’une étape à une autre, puis d’y revenir pour approfondir un point. Cette démarche permet souvent de clarifier des idées qui, au départ, semblaient floues.

Dernière pensée sur les apports du Domain-Driven Design

Ce tour d’horizon du DDD vous a sans doute permis de mieux comprendre la diversité des outils et méthodes utilisés. C’est un point à la fois remarquable et essentiel. Godefroy Clair, qui a assisté à la formation DDD avancée, a proposé une synthèse précieuse offrant une vue d’ensemble claire et complète du Domain-Driven Design.

Pourquoi opter pour l’approche DDD plutôt qu’une autre ? C’est une excellente question, dont la réponse repose sur six valeurs fondamentales qui, nous l’espérons, sauront vous convaincre.

L’approche DDD est pragmatique car elle s’ancre dans la réalité du terrain, itérative parce qu’elle progresse étape par étape, dialectique grâce aux échanges réguliers avec les experts métier, pluraliste en reconnaissant qu’il n’existe pas une seule vérité, holistique en intégrant l’ensemble du système, et en perpétuelle évolution pour rester en phase avec les besoins du terrain.

De nombreux acteurs de la sphère IT peuvent en tirer des bénéfices concrets : une organisation plus claire, une communication plus fluide, un impact renforcé sur le produit, une meilleure qualité logicielle, et une réduction de la charge cognitive des équipes. Les principes du DDD sont simples et inclusifs, loin d’être élitistes, mais ils exigent du temps pour être pleinement compris et intégrés. En s’appropriant ces valeurs, les développeurs gagnent en compréhension, jusqu’à devenir plus autonomes et responsables dans leurs choix. Finalement, ne faut-il pas parfois ralentir… pour mieux accélérer ?

Pourquoi sommes-nous passés à côté du DDD ?

DDD est perçu comme trop élitiste

Le Domain-Driven Design n’est pas une méthode miracle, ni un luxe réservé aux architectes ou aux experts autoproclamés. C’est un cadre pensée pragmatique, un levier puissant pour sortir du chaos organisationnel et redonner un cap clair à nos projets.

Aujourd'hui, le temps nécessaire à la prise de recul fait défaut. Il devient difficile de s'arrêter pour réfléchir à une approche permettant de modéliser à la fois l'organisation d'un domaine métier et les modèles propres aux équipes concernées.

Dans ce contexte, l’approche du Domain-Driven Design (DDD), qui repose sur une modélisation ancrée dans le temps long, entre en tension avec l’absence de vision déterministe à court terme.

Les projets subissent une pression court-termiste

La vision produit est souvent éclipsée par une logique budgétaire à court terme, qui ne laisse pas l’espace nécessaire à une véritable prise de recul pour comprendre en profondeur le problème métier. En conséquence, les solutions proposées manquent de fond : elles sont conçues sans l’analyse approfondie indispensable à l’exploration de la complexité métier.

Les développeurs sont peu formés au métier

Côté équipes de développement, la situation s'apparente parfois à une mission impossible : les besoins sont mal définis, révisés à la hâte, et ce, sans ajustement des délais de livraison. Résultat : un stress important pour l’équipe, qui n’a ni le temps de réfléchir ni celui d’itérer correctement. Cela conduit à l’apparition de nombreux code smells et, à terme, à une base de code difficilement maintenable.

Dans ces conditions, comment espérer que l’équipe puisse se former au domaine métier, échanger avec les experts, et confronter sa compréhension aux réalités du terrain ?

Les organisations privilégient la vitesse à la compréhension

Dans un environnement dominé par le stress et l’urgence, la peur tend à prendre le pas sur le bon sens et la capacité à prendre du recul. C’est dans ce chaos silencieux que beaucoup d’entreprises s’épuisent. Or, construire vite sans comprendre, c’est souvent devoir reconstruire deux fois.

Les sirènes de l’IA générative vont-elles vraiment sauver les entreprises ? Il devient difficile d’échapper à la vague de l’IA générative et aux promesses du "vibe programming". À ceux qui espèrent un miracle, rappelons humblement que ces technologies reposent sur des modèles probabilistes, entraînés à partir de vastes corpus – souvent l’ensemble du web, voire plus.

Or, la complexité du métier réside précisément dans la singularité des contextes, des règles implicites, et des nuances humaines. L’IA générative peut être un outil précieux, mais elle reste peu adaptée à des problématiques profondément spécifiques ou complexes. Elle complète, elle ne remplace pas la compréhension métier.

Sortir du chaos IT : Et si le Domain-Driven Design était la réponse ?

Dans de nombreux projets IT, une déconnexion insidieuse s’installe entre les équipes techniques et les experts métier. Cette fracture, souvent sous-estimée, engendre une perte de sens, des décisions techniques inefficaces, et du code difficilement maintenable. Les audits se succèdent, et leurs conclusions se répètent : tout est à reconstruire.

Sous la pression constante — crises, urgences, délais — la qualité logicielle est reléguée au second plan. Les sprints s’enchaînent sans cap, l’organisation glisse vers le chaos. Et pourtant, les équipes ne ménagent pas leurs efforts. Mais la surcharge devient chronique, l’épuisement s’installe, et l’initiative s’éteint, étouffée par la peur de l’échec.

L’urgence et le stress ne font pas bon ménage avec une modélisation fine et profonde**.** Notre cerveau a besoin de calme et de temps pour assimiler, faire des liens, et construire une vision d’ensemble. Comprendre véritablement un modèle, ce n’est pas juste l’entendre : c’est l’explorer, le questionner, le relier à ses propres repères. Autrement dit, pour qu’un apprentissage devienne opérant, il doit avoir le temps de mûrir (J’ai écrit un article sur ce sujet).

Ce que le Domain-Driven Design apporte comme réponse

Réconcilier technique et métier

Le DDD invite à une collaboration étroite entre développeurs et experts métier, fondée sur un modèle conceptuel partagé et un langage commun (Ubiquitous Language). Cette approche restaure le dialogue, favorise la compréhension mutuelle, et redonne un sens clair à chaque ligne de code.

Mettre le sens au cœur de la conception

En plaçant la compréhension du domaine au centre du processus de développement, le DDD aligne les choix techniques sur les véritables enjeux de l’organisation. Les décisions retrouvent leur légitimité, et les équipes se connectent à une vision d’ensemble.

Structurer avec cohérence

Grâce à la notion de Bounded Contexts, le DDD permet de structurer le système en sous-domaines logiques et autonomes. Résultat : une architecture plus claire, plus stable, et bien plus facile à faire évoluer.

Renforcer l’agilité, la vraie

Le DDD valorise l’apprentissage continu, les itérations fonctionnelles et l’adaptation au changement. Il ne se contente pas d’optimiser l’exécution : il invite à concevoir des solutions de manière collaborative, avec et pour le métier.

Pour aller plus loin

Dans cet article, j’ai tenté humblement de vulgariser le Domain-Driven Design afin de le rendre accessible à toutes celles et ceux qui conçoivent, développent ou pilotent des produits numériques.

Si vous souhaitez découvrir concrètement le Domain-Driven Design et vivre les ateliers qui le rendent si puissant, cette formation est faite pour vous.

Au-delà d’une simple méthode qui place le métier au centre de l’organisation comme du code, le Domain-Driven Design (DDD) est avant tout une approche pour concevoir des logiciels à la fois utiles, robustes et profondément ancrés dans la réalité du domaine.

Prenez le temps de découvrir cette démarche, un sujet à la fois. Tenter d’embrasser l’ensemble de l’approche d’un seul coup serait contre-productif.

Progressez pas à pas, appréciez les ateliers, explorez les patterns, et allez plus loin pour enrichir vos connaissances.

Vous y développerez une compréhension fine des concepts clés du DDD, et repartirez avec des leviers concrets à activer dans votre entreprise.

Quelques références pour creuser le sujet

Pour aller plus loin dans votre exploration du Domain-Driven Design et de ses thématiques connexes, voici quelques ressources qui pourraient enrichir votre réflexion.

Voici quelques ouvrages essentiels pour comprendre plus en profondeur le Domain-Driven Design:

Bien modéliser en dépassant une vision superficielle du domaine

La clé pour maîtriser la complexité réside dans un bon modèle de domaine, un modèle qui dépasse une vision superficielle du domaine en introduisant une structure sous-jacente, offrant ainsi aux développeurs le levier dont ils ont besoin. Un bon modèle de domaine peut être d’une valeur inestimable, mais ce n’est pas quelque chose de facile à concevoir. Peu de personnes savent le faire correctement, et il est très difficile à enseigner.

Bien moderniser ses architectures en collaborant

L’alignement socio-technique du logiciel, de la stratégie et de la structure vous guide à chaque étape de votre parcours de modernisation : de l’élaboration d’un business case convaincant à l’animation d’ateliers, en passant par le renforcement des compétences de vos équipes avec de nouvelles méthodes de travail.

Bien collaborer afin de bien modéliser

Comment faciliter les décisions de modélisation de domaine est un guide pratique pour mener des sessions de conception logicielle efficaces, impliquant l’ensemble des parties prenantes métier et techniques. Il expose des techniques pragmatiques pour prendre des décisions de conception de façon collaborative, garantissant la participation et les contributions de tout le groupe afin de résoudre de véritables problématiques métier.