Event Storming : modélisez votre domaine métier en équipe

J’ai participé il y a peu à une session d’Event Storming et je souhaite partager avec vous cette nouvelle expérience.

L’Event Storming , c’est quoi ?

L’Event Storming est une approche créée par Alberto Brandolini permettant de vous aider à modéliser votre domaine métier en équipe. Cela peut sembler assez basique, mais c’est vraiment efficace !

Vous souvenez-vous la dernière fois où vous vous êtes posé tous ensemble, développeurs et experts métier, dans le but d’échanger à propos d’une nouvelle fonctionnalité, discuter d’améliorations ou même confirmer un fonctionnement existant ?

Il peut y avoir, pour diverses raisons, un manque de compréhension du métier, ou une vision qui diffère d’une personne à l’autre.

C’est là où l’Event Storming est intéressant ! Cela va vous permettre de modéliser votre domaine métier en ayant un réel échange entre experts métiers, développeurs et parties prenantes afin que tous aient la même compréhension du métier (Ubiquitous Language – DDD).

Avant de commencer

J’utiliserai principalement tout au long de cet article, les termes anglophones de DDD et de l’Event Storming, qui seront, je pense, compris par une majorité de personnes.

Voici maintenant une liste de prérequis et de recommandations qui vont vous permettre de réaliser cet atelier dans de bonnes conditions !

L’environnement et les personnes

L’environnement est important pour le bon déroulement de l’Event Storming. Dans l’idéal, une pièce avec un grand espace mural (sans avoir l’impression d’être limité) serait parfaite !

Les personnes présentes (8-10 max), peuvent aussi bien faire partie de l’équipe de développement, qu’être experts métier ou parties prenantes. Pour des raisons évidentes, la présence d’experts métier est plus que recommandés.

Il y aura également le rôle du facilitateur, qui s’assurera du bon déroulement et de l’animation de l’atelier, sans prendre état sur ce qui est discuté.

Bien sûr, pour que cela soit efficace, il faut que l’environnement soit propice à la discussion, que tout le monde puisse échanger sans crainte, dans un cadre bienveillant.

Le matériel

L’atelier ne requiert pas beaucoup de matériel, des post-it de différentes tailles et couleurs, ainsi que d’un feutre par personne sera suffisant.

Accessoirement, un grand rouleau de papier à dessin (de plusieurs mètres) à scotcher au mur peut également être un atout. Dans ce cas, les post-it pourront y être collés, le rouleau complet conservé si besoin et surtout la possibilité d’ajouter des annotations au feutre.

La durée

L’atelier ne devrait pas durer plus de deux heures « en théorie  ». Mais pour l’avoir exercé à plusieurs reprises, cela me semble assez difficile de s’y tenir, surtout durant votre phase de découverte.

Je vous conseille aussi d’avoir un « Time Keeper » (gardien du temps), probablement le facilitateur, qui vous dira quand faire une pause ou arrêter l’atelier.

Il se peut que vous ne puissiez pas finir votre atelier en une seule fois. Je n’ai pas vu de recommandation particulière à ce sujet, mais j’ai envie de vous dire, si vous souhaitez organiser une autre session pour continuer / terminer, allez-y !

Les Domain Events : c’est parti !

L’atelier commence par ce que l’on appelle les événements métiers ou domain events en Anglais, représentés par des post-it orange (le facilitateur doit s’assurer que la légende soit bien visible de tous).

Ce sont des événements clés de votre métier, qui ont déjà eu lieu et qui ne peuvent plus changer. Ils se représentent par une phrase / verbe au passé et sont placés dans un ordre, si possible, chronologique (suivant une Timeline / ligne de temps) sur le mur ou rouleau de papier :

Si l’on prend comme exemple un site d’e-commerce, lorsque l’on ajoute un article à son panier, on peut tout à fait penser qu’il existe un événement métier, tel que « Article ajouté » :

C’est ainsi que débute donc l’atelier, chacun essaie d’identifier les domain events en relation avec le contexte métier traité et de les coller (pendant quelques minutes). N’hésitez pas à profiter de toute la place à votre disposition !

Cela peut être difficile d’amorcer l’atelier, mais les participants doivent faire un effort pour sortir de leur zone de confort et collaborer.

Astuce : le facilitateur peut pendant la préparation de la salle, enlever ou éloigner les chaises présentes, afin que tout le monde se mette dans l’action plus facilement, en restant debout !

Après avoir collé les post-it, tout le monde échange, afin de supprimer les événements identiques, pour qu’il n’en reste qu’un (méthode Highlander ?) et demander d’éventuelles clarifications.

Les Commands

Une fois l’atelier lancé avec les domain events, suivent les commands (ou commandes en français).

Une commande représente une action et s’écrit sur un post-it bleu en y suggérant l’intention avec un verbe à l’impératif.

Si l’on reprend l’exemple précédent de l’e-commerce, une commande pourrait être « Ajouter article » :

Bien souvent, elle est déclencheur d’un domain event et se placera juste avant celui-ci :

Notez qu’une commande pourrait tout à fait déclencher plusieurs domain events si cela était nécessaire.

Les Acteurs

Un « Actor » est une personne à l’origine d’une action (bien souvent une commande). Ils sont notés dur des post-it jaunes avec le petit dessin d’une personne.

L’objectif à travers cet atelier est vraiment de faire ressortir le métier et ses termes, et bien souvent cela commence par des acteurs qui peuvent avoir des noms / rôles bien spécifiques.

Je vais mettre entre parenthèses notre e-commerce, pour changer totalement de contexte, et vous donner quelques exemples :

• La personne à l’entrée, dans un casino de jeux, avec des aptitudes pour reconnaître les clients, s’appelle un(e) Physionomiste ;
• La personne qui contrôle votre ticket de train s’appelle un(e) Contrôleur ou Contrôleuse ;
• Une personne qui n’est pas encore client, mais qui pourrait l’être, peut s’appeler un Prospect.

Si maintenant l’on reprend notre exemple, le Client semble l’acteur à l’origine de la commande « Ajouter Article ». L’on positionnera ainsi notre nouveau post-it sur la commande qu’il exécute :

L’atelier est un endroit adapté pour discuter des différents acteurs trouvés et de leurs rôles qui peut être assez spécifique.

Les Policies

Que faire lorsqu’une commande doit être exécutée, suite à un domain event mais uniquement sous certaines conditions ? Et bien c’est là que les Policies entre en jeu.

Une Policy peut aussi bien être un traitement que des règles métiers, et est notée sur un post-it rose.

Il faut noter qu’il y a deux types de Policy :

• Système : Le plus couramment, celles qui vont se retrouver dans votre système et dont l’origine est un événement métier.
• Humain : Dans certains cas, le métier est simple et plutôt lié à une routine humaine, dans ce cas-là la policy ne se répercutera pas dans le système et l’on pourra coller l’actor qui déclenche la policy.

Essayez de déterminer les policies de votre contexte, chaque personne de l’atelier devrait pouvoir en trouver une ou plusieurs.

Comme pour les étapes précédentes une fois les post-it collés, il faut en discuter et supprimer les doublons pour passer à l’étape suivante : les systèmes externes !

Les External Systems

Il est possible que vous ayez besoin de divers external systems (systèmes externes) pour le bon fonctionnement de votre produit, ils seront notés sur de larges post-it de couleur fuchsia.

Les systèmes externes sont en général à l’écoute de domain events (un Middleware Oriented Message – Messaging est souvent utilisé dans ces scénarios) afin de déclencher une commande et effectuer un traitement spécifique.

Pour vous donner un exemple, l’on souhaite envoyer un email au client, lorsque la commande est passée.

L’envoi de cet email pourrait se faire à travers un système externe, tel que « Mailchimp » qui serait à l’écoute de l’événement métier « Commande passée » pour ensuite envoyer un email au client :

Les systèmes externes peuvent tout à fait déclencher eux-mêmes des domain events, s’il y en a la nécessité.

Utilisez-vous ou pensez-vous utiliser des systèmes externes ? 

Les Reads Model

Avant de vous parler des reads model, j’aimerais aborder très rapidement le grand principe à la base d’une architecture CQRS (Command Query Responsibility Segregation) ou Séparation commande-requête en français.

Derrière cet acronyme un peu barbare, se cache un principe simple qui consiste à séparer la lecture (Query) de l’écriture (Command). Il y a une réelle volonté de séparer les composants qui permettent de requêter les données de ceux qui vont les modifier.

Ça ne vous rappelle rien ? Les commandes dont on parle depuis le début de l’atelier sont parfaitement alignées avec cette définition, et il en va de même avec les queries, qui sont représentées par des reads Model.

Pour clarifier la notion de read model, on pourrait dire que ce sont des informations (en lecture) nécessaires pour prendre une décision. Cela va souvent de pair avec l’interface utilisateur (User Interface – UI ) qui permet à un acteur de faire un choix avant de déclencher une commande.

Ils sont ainsi souvent liés à l’interface utilisateur, et s’écriront sur des post-it verts, avec les informations à utiliser / afficher.

Pour continuer avec notre e-commerce, avant que le client ne puisse ajouter un article, il lui sera d’abord nécessaire de sélectionner son article à ajouter, et cela depuis une liste d’articles :

Les Aggregates

L’agrégat est un pattern en Domain-Driven Design. Un agrégat DDD est un regroupement d’objets du domaine qui peuvent être traités comme une seule et même unité.

Martin Fowler – martinfowler.com

L’idée derrière un agrégat, est que toute entity / value object (voir DDD), qu’il contient ne peut être manipulé que par un unique objet, aussi appelé aggregate root en anglais.

Ils peuvent être plus ou moins facile à identifier, bien souvent leur nom se retrouve dans des commandes et domain events assez proche.

Les agrégats seront notés sur de longs post-it jaunes (plus grands que ceux utilisés pour les acteurs) et peuvent se placer au-dessus de ce qui semble être une fonctionnalité identifiée.

Dans notre exemple d’e-commerce nous pouvons en sortir l’agrégat « Commande » (à ne pas confondre avec les commands – post-it bleu) :

Il est très probable que vous identifiez plusieurs fois le même agrégat, c’est normal ! Dans ce cas-là pour des raisons pratiques de lisibilité, vous pouvez utiliser plusieurs post-it avec le même nom d’agrégat écrit.

Astuce : Attention toutefois à ne pas avoir d’agrégat trop gros (super agrégat) qui gérerait tout votre domaine métier.

Si jamais vous identifiez des agrégats avec trop de responsabilités, il y a de fortes chances que vous deviez en discuter en équipe afin d’augmenter la granularité et trouver de nouveaux agrégats plus petits et plus adaptés.

Les Bounded-Contexts

Le pattern stratégique bounded context (contexte borné) provient directement du Domain-Driven Design (DDD). Concrètement, un bounded context représente une frontière logique entre différents ensembles de fonctionnalités de votre domaine métier.

On ne pourra cette fois pas les afficher avec des post-it, mais vous pouvez déjà commencer par regrouper les post-it collés qui sont en étroite relation. Cela devrait permettre de faire apparaître plus facilement les bounded contexts.

Astuce : Un feutre ou du scotch de couleur peut aussi vous aider à définir les frontières des différents bounded contexts.

Concrètement, dans notre e-commerce, si l’on allait plus loin, on pourrait se projeter avec ces bounded context :

• Sales (Vente) : contexte borné qui traite les articles, la commande et tout ce qui est lié à la vente de façon générale.
• Billing (Achat) : ce contexte permettrait de gérer le paiement de la commande (Carte de crédit, Paypal, etc.)
• Shipping (Expédition) : contexte permettant de gérer la livraison de la commande (adresse postale, suivi, etc.)
• Notification :  contexte borné permettant de gérer l’envoi de notifications, tel que des emails.

À cette étape de l’atelier, il doit probablement ressortir divers bounded context bien distinct, avez-vous pu les identifier ?

Pour aller plus loin

Les autres déclencheurs

Il existe à ma connaissance d’autres types de déclencheurs comme le temps, avec ou sans récurrence. Dans ce cas, vous pouvez les noter sur les mêmes post-it orange que les domain events, avec les conditions temporelles.

Par exemple, s’il y a dans votre système un traitement à effectuer tous les 1^ers de chaque mois :

Les doutes à clarifier

Il arrivera que l’équipe ne soit pas toujours alignée sur certains post-it et c’est normal !

Quelquefois, le manque d’informations ou de recul empêche l’équipe de prendre sereinement une décision sur le moment.

Dans ce cas, l’on peut reporter ce choix à plus tard durant l’atelier, en espérant avoir par la suite l’information ou le déclic qu’on attendait.

Pour que cela ne soit pas omis et soit clairement représenter sur le mur, les post-it à clarifier, qui nécessite discussion, seront tourner à 45° :

Conclusion

L’Event Storming peut vraiment être un atelier qui vous aide à modéliser votre domaine métier en équipe.

Après l’avoir pratiqué quelquefois, je pense vraiment que cela a aidé l’équipe à appréhender le métier et à améliorer sa compréhension.

Vous serez d’autant plus gagnant si vous faites du Domain-Driven Design (DDD) qui est vraiment au cœur de l’Event Storming. Si vous n’avez pas encore exercé DDD, je vous recommande de lire l’un des livres disponibles ci-dessous.

J’ai essayé ici de retranscrire le déroulement des Event Storming auquel j’ai participé. Il existe plusieurs variantes, qui sont plus ou moins allégées (avec / sans read models, bounded contexts, etc.), ou bien encore certaines étapes ne sont pas traitées dans le même ordre.

Il n’y a pas vraiment de règles, essayez l’atelier et ajustez en fonction de votre contexte et de votre équipe pour qu’il soit adapté et efficace ! À vos post-it !

Références et Ressources

• Site d’Alberto Brandolini : https://eventstorming.com
• Site Miro, permet de créer des boards online et en temps réel :  https://miro.com

• Livre Domain-Driven Design: Tackling Complexity in the Heart of Software, d’Eric Evans (le blue book).

• Livre Implementing Domain-Driven Design, de Vaughn Vernon (le red book).