Suite à mon introduction sur l’Event Storming, j’ai envie de compléter un peu en revenant sur les différents ingrédients à notre disposition pour composer un Event Storming. Je trouve qu’on a une grande richesse. On a une large boîte à outils pour modéliser notre système et harmoniser les modèles mentaux, tout en restant simple d’usage.

J’ai présenté certains éléments dans mon précédent article, ici je ferais une liste plus complète afin d’avoir une vision globale et rapide de ce qu’on peut utiliser. On pourra ensuite voir les interactions entre les éléments. Individuellement, chaque ingrédient apporte un type d’information, mais ensemble, ils forment un tout et agissent sur les autres.

Les différents éléments

Domain Event / Événement

Avec les événements, on construit la colonne vertébrale. C’est ce qu’il se passe dans notre système. Les événements sont décrits par un verbe au participe passé. « Facture générée », « Commande livrée ». C’est quelque chose qui a eu lieu. C’est très important. On veut forcer les participants à penser avec des actions achevées, des changements d’état, des choses qui peuvent agir comme un déclencheur pour une autre action.

Les événements forment la base de l’Event Storming, tout tourne autour des événements. C’est compréhensible par le métier, par tout le monde. On peut raconter une histoire avec. On aura forcément les événements dans cet atelier, et on commence d’ailleurs par cette étape.

Actor / Acteur

Les acteurs interagissent avec le système, ils déclenchent des commandes. Ils initient une action qui va produire un événement. Ce peut être un utilisateur ou une partie d’un logiciel, un système. On essaie d’être assez précis avec la dénomination de l’acteur, de représenter ce qu’il est vraiment, son nom, son rôle. « Le client », « Le livreur », « Le système Y ». On utilise très souvent les acteurs car on veut visualiser qui fait quoi.

External System / Système Externe

Ce sont les dépendances. On veut visualiser ce qui est à l’extérieur de notre système, ce qu’on ne gère pas. On veut aussi voir apparaître les adhérences auxquels est soumis le système, ce qui le contraint, les goulots d’étranglement. « Le fournisseur », « Service Z ». Tout comme les acteurs, on veut voir qui fait quoi, et cette fois-ci, on a une information supplémentaire - c’est quelque chose d’extérieur.

Command / Commande

La commande est le déclencheur d’un événement, souvent une conséquence d’une action utilisateur, une prise de décision d’un acteur ou d’un système externe. On parle de l’action réalisée qui sera le déclencheur d’un ou plusieurs événements avec un verbe à l’infinitif. « Ajouter au panier ». Il n’y a pas forcément une commande sur chaque événement.

Avec les commandes, on commence à être plus précis sur le processus et on se projette également un peu dans le code.

Policy / Règle

Une Policy permet de rendre explicite une règle métier. C’est la glu qui lie un événement et une commande. Avec une Policy, on représente des commandes qui sont exécutées suite à un événement et selon une condition précise. En général, on décrit une Policy avec Lorsque ... alors ... : « Lorsque le paiement dépasse 500 €, alors il faut envoyer un SMS à l’utilisateur ».

Les Policies peuvent être présentent dans un système, qui gère cette règle lorsque l’événement correspondant se produit. Ce peut également être un humain qui agit lorsqu’un événement se passe. Par exemple, « Lorsqu’une fraude est détectée, alors il faut appeler le client ». C’est un processus humain. Dans ce cas-là, on peut ajouter un post-it acteur sur la Policy pour représenter la personne.

Read Model / Données

Il y a une nuance importante dans le nom anglais, Read Model. On va parler des données que l’on affiche et qui vont aider les acteurs à prendre des décisions. On ne parle pas des données que l’on écrit (écriture dans une base, un registre…), ces informations sont déjà indiquées dans les commandes comme « Ajouter (l’article) au panier ».

On y écrit les données principales. « Nom, Prénom, Email ». On se limite pour mettre en valeur ce qui compte réellement.

Aggregate / Agrégat

Les agrégats vont apporter une vision bien plus micro et être très proche du code. Pour paraphraser Martin Fowler, un agrégat est un regroupement d’objets du domaine qui peuvent être manipulés comme un seul objet. C’est un pattern qui vient du Domain-Driven Design.

Ce regroupement a du sens pour le métier. On préfèrera manipuler l’agrégat plutôt que chaque objets individuellement - ces objets sont cohérents s’ils sont manipulés ensemble. Dans l’exemple du e-commerce, on peut imaginer un agrégat « Panier » qui contiendrait plusieurs objets « Article » et un objet « Promotion ».

L’intérêt en faisant émerger les agrégats avant de se plonger dans le code va être de visualiser où ils se retrouvent, s’il n’y a pas trop d’événements ou commandes autour d’un même agrégat.

Hot Spot / Point d’attention

Tout au long de l’atelier, on peut marquer les désaccords, les questions, les risques, etc. Ça fait partie du modèle. On peut marquer tout ce qui s’éloigne du scénario nominal pour rester concentré. Ce seront des éléments à creuser plus tard. « Attention RGPD », « Que fait X ? », « Risque de fraude de paiement ». On veut également les visualiser pour mettre en lumière les zones d’ombres, les questions, les problèmes. On agira peut-être là-dessus suite à l’atelier.

Déclencheur temporel

Le temps est parfois aussi un déclencheur d’action. Par exemple, une sauvegarde qui doit être réalisée toutes les heures. On marquera alors simplement « Toutes les heures » sur le post-it. Ce sera le déclencheur d’une commande ou d’un événement visant à créer une sauvegarde.

Bounded Context / Contexte borné

Une fois la modélisation du système bien avancé, dessiner les Bounded Context va permettre de définir les contours des domaines et sous-domaines métiers. En les identifiant, en les explicitant, on veut faire émerger des périmètres métier cohérent, des services, des ensembles de fonctionnalités, des contextes à l’intérieur desquels les objets, les mots, le vocabulaire auront un sens important. On peut aussi visualiser comment ils interagissent entre eux.

Dans une plateforme d’e-commerce, on pourrait imaginer plusieurs contextes : le service client, le service achats, le service livraison. Le terme « client » n’a peut-être pas la même signification au sein des trois services. Peut-être même que le terme est différent, le service livraison pourrait parler de « destinataire ».

Les interactions entre les éléments

Individuellement, tous ces éléments sont simples et apportent un niveau de compréhension différent. L’acteur informe sur qui prends la décision, l’événement indique ce qu’il s’est passé.

Ensemble, ils forment un tout. Ils se complètent, et certains ont une interaction directe entre eux. Quand un acteur agit, il déclenche une commande. Quand une commande est exécutée dans un système, un événement se produit.

Je trouve intéressant de voir comment chaque élément se comporte avec les autres et ce schéma (venant d’Alberto Brandolini, le créateur), le représente bien. C’est intéressant pour la compréhension de l’Event Storming, pour modéliser, et aussi pour concevoir plus tard le logiciel.

Une commande est exécutée. « Ajouter l’article au panier ». Une décision a été prise, il y a une action, quelque chose doit se passer. Cette commande se produit dans un système. Ce peut être le nôtre, auquel cas elle agira sur un agrégat. « On ajoute un Article au Panier, on applique éventuellement une Promotion, on recalcule un prix total ». Ou ce peut être dans un système externe.

Par l’action de cette commande, le système en question génère un événement. « Article ajouté ». Cette fois-ci, ça a eu lieu, l’histoire a évolué. Il s’est passé quelque chose dans le système.

Avec cet événement, un état a changé. On peut projeter de nouvelles données « il y a 5 articles dans le panier, le nouveau prix total est de 343 euros » et les afficher dans une nouvelle interface graphique.

L’événement peut déclencher une règle, une Policy. Le système réagit à cet événement si une condition particulière est rencontrée. « Lorsque le panier contient 5 articles, alors une réduction de 20% est appliquée sur l’article le moins cher ». Une commande est alors exécutée. « Appliquer la promotion ».

Qui d’autre peut être à l’origine d’une commande ? Un acteur. « Le client » a lancé la commande « Ajouter l’article au panier ». C’est lui qui a pris la décision, qui a agi.

Une commande est donc exécutée par un acteur ou par une règle provenant d’un système. Qui produira un événement. Et ainsi de suite. La boucle est bouclée.