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 ?

Event Storming

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

Post-it

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.

Feutres

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 !

Domain Event

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 :

Timeline

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é » :

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).

Commande

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 :

Exemple de Commande

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

Les Acteurs

Actor

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 :

Exemple d'Actor

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.

Policy

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

Exemple de Policy

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.
Policy avec Actor

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 :

Exemple Système Externe

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.

Read Model

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.

Aggregate

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 1ers 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

2 commentaires sur “Event Storming : modélisez votre domaine métier en équipe”

  1. Bonjour, j’ai une question concernant les « Domain Events ».
    Lorsque je regarde des exemples d’event storming je constate parfois des Domain Events qui ressemblent à cela :
    – Order cancellation Requested
    – Add to Cart Requested
    – Ticket Requested
    – Create Account Requested
    – …

    Est-ce une bonne pratique que de créer des post-it orange pour chaque Request ?
    Car j’ai le sentiment que si je commence à noter chaque événement de type « Demmande » alors je vais devoir multiplier par deux le nombre d’événement avec
    – 1 Post-it orange pour la demande « Create Account Requested », « Add to Cart Requested  » …
    – 1 Post-it orange pour le resultat « Account Created », « Added to Cart »

    Je vous remercie pour votre future réponse .

    1. Bonjour Enzo,

      Je pense que tu touches du doigt une partie qui peut être facilement mal interprétée.

      Les « Requested » semblent effectivement être des événements, mais sont à mon sens des commandes (post-it bleu), et non pas des événements métier (domain events).

      Pour reprendre ton cas, avec la commande « Create Account » (post-it bleu), un événement métier « Account Created » devrait être levé (post-it orange).

      J’espère t’avoir éclairé, voici deux autres sujets étroitement liés qui peuvent t’intéresser:
      – CQRS (Command Query Responsibility Segregation) pattern
      – DDD (Domain-Driven Design)

Laisser un commentaire