02. Techniques de l'EventStorming

🧩 Cet article fait partie d’une série sur l’EventStorming

Dans le développement logiciel, la compréhension fine du métier est souvent le point de friction principal entre les experts métier et les équipes techniques. C’est là qu’intervient l’EventStorming, une méthode de modélisation collaborative puissante qui permet de visualiser, d’explorer et de structurer les processus métier complexes de manière efficace et intuitive.

Les 3 formats d’EventStorming

Au fil des années, trois grands types d’ateliers ont émergé :

• Big Picture EventStorming : cartographier tout un domaine ou un ensemble de processus métier.
• Process Modelling EventStorming : se concentrer sur un processus spécifique.
• Software Design EventStorming : modélisation orientée vers la conception logicielle, souvent couplée au DDD (Domain-Driven Design).

Big Picture

Le format Big Picture EventStorming est le plus vaste. Il mobilise souvent 25 à 30 participants issus de tous les niveaux de l’organisation. L’objectif est d’explorer l’ensemble d’une ligne métier, du début à la fin.

01. Domain Events

Les participants racontent les événements majeurs qui jalonnent les processus de leur organisation, en les positionnant chronologiquement. Cela se traduit par des Domain Events (post-its oranges).

Les événements métier racontent une histoire compréhensible par le métier.

02. Commands / Persons

On ajoute ensuite les commandes et les acteurs sur ces commandes.

Notre histoire s’enrichit à travers les commandes, qui résultent souvent d’une action d’un acteur et déclenchent des événements métier.

03. External Systems

On peut ensuite ajouter les systèmes externes.

Notre histoire continue d’évoluer, certains systèmes externes sont identifiés. Ces systèmes jouent un rôle dans l’apparition d’un événement métier.

Process Modeling

Après le format Big Picture, le second format s’appelle Process Modeling. Il vise un niveau de granularité plus fin, tout en restant du côté métier – on ne descend pas encore dans la conception logicielle.

On y modélise un processus spécifique, de bout en bout, en y ajoutant plus de rigueur sur l’utilisation des éléments de la Big Picture et en ajoutant de nouveaux éléments (policie et read model)

Ce format permet :

• D’analyser un processus existant en profondeur,
• D’explorer des variantes ou des scénarios alternatifs,
• De concevoir de nouveaux processus à partir de l’expérience terrain,
• D’identifier les goulots d’étranglement, risques, ou opportunités d’automatisation.

Il est particulièrement utile dans les contextes de transformation opérationnelle ou d’amélioration continue.

04. Policies

Dans notre histoire, on identifie - à travers les policies - les règles qui existent lorsqu’un événement se produit.

Une policy peut également servir à introduire un comportement conditionnel dans la description du processus.

05. Read model

Ici, le read model Order Summary est un écran qu’on présente à l’acheteur et qui lui permet de vérifier sa commande avant d’exécuter le paiement.

Software Design

Le dernier format s’appelle Software Design. Il fait le lien entre les événements du métier et leur implémentation logicielle potentielle. On y introduit des éléments supplémentaires dans la grammaire (les aggregates, et les contextes bornés). Cela permet d’augmenter la précision de la discussion, tout en conservant un fort ancrage métier.

Ce format est particulièrement pertinent pour :

• Concevoir une architecture logicielle alignée sur le métier,
• Identifier les interfaces entre domaines,
• Définir des limites de responsabilité claires,
• Éviter les couplages inutiles,
• Préparer la modélisation orientée DDD.

Il s’agit du format le plus technique, mais il garde une forte valeur collaborative en maintenant le dialogue constant entre experts métier et développeurs.

06. Aggregates

Dans notre scénario, voici les agrégats que nous pourrions ajouter :

• Payment - Si le paiement devient un processus complexe à part entière
• Shipment - Pour gérer finement les livraisons (multi-colis, tracking)
• ProductInventory - Pour intégrer la gestion de stock (en lecture/écriture)

En pratique, un aggregate est une classe métier qui fait autorité sur un sous-domaine. Pour les agrégats, on met l’accent sur le comportement, pas sur les données - dans l’esprit de la programmation orientée objet. Toutes les règles métier doivent être appliquées et garanties par cet agrégat.

De la commande à l’événement

Que ce soit un aggregate ou un external system, ces “morceaux de software” servent souvent à transformer une commande en event

Résumé des post-its utilisés

Nous avons essayé de rester proches du standard, notamment en ce qui concerne le nom et la couleur des post-its. Cependant, il est important de comprendre qu’il est possible de prendre beaucoup de libertés avec ces conventions.

Voici un exemple présenté par Nick Tune lors d’un atelier :

• Le context, qui représente un aggregate, a la même couleur qu’un external system.
• Le read model est appelé query, car ici le premier event effectue un appel vers le second pour obtenir des informations (read model).

En savoir plus : organiser un workshop pour découper un monolithe en microservices