La Duck Conf 2025 - Vivez l'expérience d'une modélisation orientée Domain-Driven Design - Compte rendu de l'atelier de Bruno Boucard et Godefroy Clair
Avez-vous déjà entendu un client dire suite à un développement: « Ce n’est pas cela qu’on voulait ! » ? Probablement ! ☹️
Lors de cet atelier à la Duck Conf 2025, la première conférence entièrement dédiée à l'architecture de SI organisée par OCTO Technology, Bruno et Godefroy ont commencé par nous rappeler comment Eric Evans, le père du DDD avec son livre « Domain Driven Design », a eu l’idée de ce concept suite à une mise en production infructueuse causée par des interdépendances non maîtrisées entre deux équipes.
En 1h30, cet atelier nous explique les raisons de la création du Domain Driven Design, les notions qui y sont associées, les différents ateliers à mener pour affiner la compréhension du métier, et enfin met en pratique le DDD via le Model-Driven Design en prenant comme exemple un cas métier concret.
Le cas métier de l’atelier est celui d’un système de réservation de places de théâtre qui, en fonction des souhaits de placement (des places au centre d’une rangée, proches de la scène, des places adjacentes …) de la personne qui réserve et du prix choisi, fait des recommandations de placement.
Pour commencer cet article, passons en revue les différentes notions et ateliers expliqués à la Duck Conf.
Les Bounded Contexts
Créer un modèle commun à la totalité du business d’une entreprise n’est généralement ni réalisable ni rentable comme le précise Eric Evans dans son livre : « Total unification of the domain model for a large system will not be feasible or cost-effective. ».
Par exemple dans le commerce en ligne, on va parler de :
- Catalogue de produits
- Panier
- Paiement
- Expédition
Chacun de ces domaines constitue ce qu’on appelle un « Bounded Context » et dispose de son propre langage bien compris des experts métier associés.
Bruno explique que l’utilisation de cette notion offre davantage d’autonomie à l’équipe et améliore la clarté du code produit.
D’autre part, comme chaque contexte relève d’une équipe distincte, l’intégrité du contexte est préservée. En effet, l’équipe en charge du catalogue ne va pas s’en aller coder dans l’implémentation du paiement !
Un langage commun
Dans le Domain Driven Design, ce langage bien compris des experts métier est appelé « Ubiquitus Language ». En Français on parlera de « Langage Ubiquitaire ».
Il n’est pas figé mais s’affine dans le temps au fur et à mesure des échanges entre le métier et les développeurs. Si des incompréhensions apparaissent, c’est qu’on ne parle pas le même langage, et il va falloir le faire évoluer afin d’éliminer ces ambiguïtés.
Dans l’exemple de réservation de places de théâtre, les notions suivantes feront partie de l’Ubiquitous Language :
- Identifiant de spectacle
- Rangée de sièges
- Agencement des sièges dans le théâtre
- Suggestion de placement demandée
- Suggestion de placement effectuée
Dispose-t-on d’un exemple ?
Le vocabulaire c’est bien, mais un exemple est toujours plus parlant.
Dans cet exemple du théâtre des Bouffes Parisiens, des places sont réservées côté scène de part et d’autres des rangées A et B.
Les places réservées sont entourées de parenthèses, et le numéro correspond à la catégorie de prix de 1 à 3, 1 étant la catégorie la plus chère.
Figure 1: Des places réservées côté scène, de part et d’autre des rangées A et B.
On commence à avoir une bonne idée du métier ! Mais comment va se passer concrètement la réservation des places ?
Pour y voir plus clair, il est nécessaire de faire un Event Storming.
Un premier atelier: l’Event Storming
Cet atelier collaboratif qui comprend les développeurs, les experts métier et produit, permet à l’aide de Post-It de matérialiser sur un tableau les flux du métier à modéliser.
On définit dans un premier temps les événements sur un Post-It d’une couleur donnée, puis ensuite les commandes qui les ont déclenchés avec une autre couleur, puis les acteurs de la commande, les systèmes externes et ainsi de suite.
Bruno explique que ce type d’atelier aboutit à une narration du métier et que les discussions qu’il suscite sont fructueuses car elles permettent d’expliciter ce qui est mal compris étant donné que chaque rôle est représenté dans cet atelier (développeur, expert métier …).
L’Event Storming conduit en particulier à distinguer le domaine cœur, le métier à implémenter, des « Supporting Domains », dont on dépend mais qui ne sont pas du ressort de l’équipe.
Un exemple typique de « Supporting Domain » est l’utilisation d’un système de paiement externe.
Dans l’exemple de la réservation de places de théâtre, l’Event Storming aboutit au résultat suivant :
Figure 2: Atelier Event Storming
L’Event Storming nous a permis d’identifier les événements métier, les commandes, les acteurs … Il est maintenant nécessaire d’affiner notre compréhension des règles métier et des cas aux limites.
Plus d’exemples avec l’Example Mapping
Un nouvel atelier, l’Example Mapping va nous permettre de zoomer sur les règles métier en les illustrant avec des exemples.
On va alors considérer les règles métier une à une et les illustrer d’un exemple passant et d’un exemple non passant.
Ces règles sont les suivantes :
- Proposer des sièges proches de la scène
- Proposer des sièges proches du centre
- Proposer des sièges adjacents
Pour chacune des règles, selon les places déjà vendues, certaines règles pourront être satisfaites, d’autres pas.
Figure 3: Atelier Example Mapping
Maintenant que nous avons compris nos règles métier, on va avoir besoin de savoir qui a la responsabilité de les implémenter ? Quelles classes définir ? Quels services ?
Les réponses à ces questions vont émerger lors de l’atelier CRC Cards.
L’atelier CRC Cards
L’atelier CRC (Class-Responsibility-Collaboration) Cards consiste en un remue-méninges (brainstorm en Anglais) utilisé dans le design d’applications. Il date des années 1980 et a été beaucoup utilisé dans l’Orienté Objet.
Il prend en entrée les scénarios ou règles métier définies lors de l’Example Mapping.
On utilise des cartes, en papier ou en bristol, sur lesquelles on écrit :
- En haut, le nom de la classe
- A gauche, les responsabilités de celle-ci
- A droite, les autres classes avec laquelle elle interagit
Bruno et Godefroy insistent sur le fait que de cet atelier vont émerger des classes possibles, ou en tous cas des candidats.
Comme dans les autres ateliers, rien n’est figé, le but étant d’affiner petit à petit notre connaissance du métier afin de l’implémenter au mieux.
Figure 4: Atelier CRC Cards
Du code avec le Model-Driven Design !
Dans la suite de cet atelier à la Duck Conf, nous avons codé deux règles métier par petits groupes, avec l’aide de Bruno et de Godefroy :
- Proposer des places au centre d’une rangée
- Proposer des places adjacentes
Comme « la complexité arrive quand il y a deux règles qui se chevauchent », nous les avons codées séparément.
« La seule chose que sait faire le cerveau humain, c'est de décomposer », insiste Bruno.
La méthode utilisée, le Model-Driven Design utilise la boîte à outils du DDD (entités, value objets, services, agrégats …), et repose sur une succession d’itérations de refactoring, qui nous conduit progressivement vers davantage de connaissance métier.
Et comme c’est le cas avec TDD, on commence par écrire un test validant la nouvelle fonctionnalité, test qui va échouer dans un premier temps.
Avec cette approche, le développeur passe régulièrement d’un rôle à l’autre : développeur et client.
Dans son rôle de développeur, il implémente techniquement une fonctionnalité.
Mais il a également un rôle client, dans lequel il observe avec les yeux du client le code qu’il vient d’écrire lui-même, en prêtant attention à ce que ce code reflète bien le vocabulaire du métier.
Comme il serait probablement assez fastidieux de lire ici les différentes étapes de l’implémentation des deux règles métier, je vous propose de regarder Bruno résoudre le même exercice comme il l’a fait à Devoxx France.
Les sources du Live Coding se trouvent sur GitHub.
Enfin, pour en savoir plus sur le DDD, vous pouvez contacter OCTO Academy qui propose deux formations sur le sujet :
Remerciements: Bruno Boucard et Godefroy Clair pour nous avoir éclairé sur tous ces sujets, Loïc Lefloch pour la prise de note efficace pendant l’atelier ainsi que les collègues qui ont relu et proposé des améliorations à cet article.
