Modélisation du domaine : l'atelier Event Storming en 3h

Chez un client dans la logistique (40 développeurs, 8 équipes, 4 ans de code accumulé), j'ai posé une question simple en réunion de lancement : "Qu'est-ce qu'une commande dans votre système ?"

Quinze minutes de débat. Cinq définitions différentes. Deux équipes qui découvraient ce soir-là qu'elles ne parlaient pas du même objet depuis des mois.

Pour l'équipe transport, une "commande" était un bon de préparation entrepôt. Pour l'équipe facturation, c'était une transaction client. Pour l'équipe livraison, c'était un shipment carrier. Ces trois concepts vivaient dans la même table de base de données. C'était la source de couplage et de bugs depuis 18 mois.

Un atelier Event Storming de 3 heures a produit la clarté que 18 mois de réunions n'avaient pas donnée. Voici comment le reproduire.

Pourquoi l'Event Storming fonctionne là où les réunions échouent

Le problème numéro un dans le développement de systèmes complexes n'est pas technique. C'est que les développeurs et les experts métier parlent des langages différents pendant des mois, et que cette incompréhension se retrouve encodée dans l'architecture.

Alberto Brandolini a créé l'Event Storming en 2013 comme une alternative aux longues sessions de recueil de besoins qui produisent des spécifications incompréhensibles. L'idée est radicale dans sa simplicité : rassembler toutes les parties prenantes dans une pièce avec des post-its de couleur, et modéliser le domaine par les événements qui s'y produisent, pas par les entités, pas par les processus, pas par les données.

En 3 heures, une équipe peut atteindre une compréhension partagée qu'elle n'aurait pas obtenue en 3 mois de réunions classiques. J'ai facilité plus de 30 sessions de ce type dans des secteurs aussi différents que la finance (Crédit Agricole), les médias (Canal+) et la logistique.

Ce dont vous avez besoin :

• Une grande surface murale (minimum 3 mètres linéaires) ou Miro/Mural pour le remote
• Post-its de 5 couleurs : orange (domain events), bleu (commands), jaune (aggregates), rose (external systems), rouge (hotspots/questions)
• 5 à 12 participants : développeurs, domain experts, PO, et éventuellement le CTO
• Un facilitateur (qui peut être vous) qui connaît les étapes
• 3 heures sans interruption

Étape 1 : Les Domain Events en orange (30 min)

Un Domain Event est quelque chose qui s'est passé dans le domaine et qui a de l'importance business. Il se formule toujours au passé : "Commande passée", "Paiement reçu", "Stock mis à jour", "Email de confirmation envoyé".

Déroulé :

1. Chaque participant écrit des événements sur des post-its orange (5 à 10 minutes en silence)
2. Tout le monde colle ses post-its sur le mur
3. Le facilitateur regroupe les événements chronologiquement, de gauche à droite

Ce que je cherche en tant que facilitateur :

• Les doublons (deux termes pour le même événement → discussion sur le terme canonique)
• Les contradictions (même nom pour des événements différents → signal de problème de domaine)
• Les trous dans la timeline (il manque des événements entre deux étapes)

Règle absolue : à cette étape, pas de jugement. Tout ce qui peut se passer est bienvenu, même les événements d'erreur et les cas limites. Les "ce n'est pas un vrai événement" de la première heure sont souvent les plus révélateurs.

Étape 2 : Les Commands en bleu (30 min)

Une Command est ce qui déclenche un Domain Event. C'est une intention, une décision : "Passer une commande", "Valider le paiement", "Envoyer la notification".

Déroulé :

1. Pour chaque Domain Event sur le mur, je demande : "Qu'est-ce qui déclenche cet événement ?"
2. Ajouter le post-it bleu (Command) à gauche du post-it orange correspondant
3. Identifier qui émet la Command : un utilisateur, un système automatique, un timer

Ce que cette étape révèle :

• Les décisions implicites du domaine (certains événements se produisent sans command explicite → probable automatisme ou logique métier cachée)
• Les acteurs du système (qui décide quoi)
• Les règles métier qui gouvernent les commands

Étape 3 : Les Aggregates en jaune (45 min)

Un Aggregate est l'entité ou le concept qui traite une Command et produit un Domain Event. C'est l'unité de cohérence du domaine, le concept central du Domain-Driven Design tel que formalisé par Eric Evans.

Déroulé :

1. Pour chaque paire Command → Domain Event, demander : "Quelle entité traite cette commande et garantit que l'événement est produit correctement ?"
2. Placer un post-it jaune entre la Command et le Domain Event avec le nom de l'Aggregate
3. Regrouper les paires Command/Event qui partagent le même Aggregate

L'exercice révélateur : Quand deux participants donnent des noms différents pour le même Aggregate, c'est un signal fort : soit c'est un problème de vocabulaire à résoudre, soit ce sont deux Aggregates distincts qui ont été confondus et qu'il faut séparer. Ce moment-là est souvent le plus productif de l'atelier.

Étape 4 : Les Bounded Contexts (45 min)

Un Bounded Context est une frontière dans le modèle de domaine où le même terme peut avoir un sens différent, ou où des équipes différentes travaillent de façon indépendante.

Déroulé :

1. Observer le mur et identifier les clusters naturels d'Aggregates qui travaillent ensemble
2. Tracer des frontières visuelles entre les clusters
3. Nommer chaque zone : "Catalog", "Ordering", "Payment", "Fulfillment"...

Les questions qui révèlent les frontières :

• "Est-ce que cette équipe parlerait à cette équipe directement, ou via un événement ?"
• "Est-ce que le mot 'Customer' a le même sens dans ces deux zones ?"
• "Ces deux zones peuvent-elles évoluer indépendamment ?"

Les post-its rouges (Hotspots) : pendant tout l'atelier, quand une question reste sans réponse, je colle un post-it rouge. Ces hotspots sont les sujets à approfondir après l'atelier : ils révèlent les zones d'incertitude du domaine et deviennent la backlog des décisions architecturales à prendre. Ces décisions méritent d'être formalisées dans des Architecture Decision Records pour garder la trace du contexte et des choix effectués.

Ce que l'atelier produit

À l'issue des 3 heures, vous disposez de :

• Une timeline des Domain Events qui représente le flux complet du domaine
• Une carte des Commands et des acteurs
• Une carte des Aggregates et de leurs responsabilités
• Des Bounded Contexts qui suggèrent les frontières de services

Ce modèle n'est pas une spec technique. C'est une langue commune entre développeurs et experts métier. Il guide directement :

• La définition des microservices (1 service par Bounded Context dans la plupart des cas), et par conséquent les décisions sur le découpage des bases de données par service
• Le design des APIs (les Commands deviennent les endpoints)
• La modélisation de la base de données (les Aggregates deviennent les tables ou collections)
• L'écriture des tests (les Domain Events deviennent les scénarios de test)

Chez le client logistique que j'évoquais en ouverture, l'atelier a révélé que l'"Order" était conceptuellement 3 choses différentes. Ces 3 concepts ont été extraits en 3 services distincts, chacun avec son architecture bien délimitée, en s'appuyant notamment sur les principes de la Clean Architecture pour garantir l'indépendance des couches. Les bugs liés au couplage ont disparu dans les 6 semaines suivantes.

Récapitulatif

FAQ sur l'Event Storming