Devenu un incontournable dans la conception d’un produit selon le concept de Domain-Driven-Design, l’Event Storming permet de cartographier les différentes actions qui influent sur votre produit logiciel ainsi que les effets secondaires qui se produisent comme le déclenchement d’autres actions dans votre écosystème IT.

Cela permet de concevoir des flux et de visualiser les différentes frontières auxquelles ces interactions vont se confronter. Avec les événements de domaine, la modélisation permet d’identifier visuellement lorsque l’on franchit une frontière entre deux composants différents. Il est dès lors plus simple d’attribuer des responsabilités à chaque élément.

Ainsi, une fois le document généré, cela devient la base de travail pour concevoir l’architecture de votre solution. Le résultat peut servir de référentiel de spécifications exécutables.

Concrètement, cela se matérialise par des cartes de différentes couleurs (post-it) :

• Jaunes « les acteurs » c’est dire les utilisateurs ou les systèmes externe qui sont à l’origine de la génération du flux ou du processus.
• Bleues « Les commandes », cela représente les comportements effectués par les acteurs qui utilisent le système, déclenchent des actions et donc génèrent un comportement. Par ex, acheter un produit dans une application e-Commerce ou tout simplement une connnexion.
• Roses ou Jaunes claires, « systèmes » ou « agrégats », une fois les actions déclenchées, elles vont entrer dans le système (Domain). Cette carte peut aussi signifier « Data » ou « Entité ».
• Oranges « Events », c’est une carte clé car lorsqu’une « commande » entre dans le système, cela exécute un certain nombre de comportements selon les règles de gestion que l’on a défini et cela génère des effets secondaires.
• Violettes « Politique », cette carte représente la nécessité de mettre en place des règles pour décider comment agir lorsque les événements ont déclenché d’autres commandes spécifiques.
• Vertes « View » ou « Projection », au-delà de la « politique », un événement peut avoir produit des effets comme une modification de données par exemple, cette carte permet de représenter cette situation.
• Rouges « Hotspot », cette carte permet d’alerter sur des doutes à dissiper ou un problème à anticiper. Elles permettent de mettre en avant des incohérences ou des éléments importants auxquels il faudra réfléchir en parallèle

Les cartes ont pour objectif de clarifier les échanges entre toutes les parties prenantes sur la base d’un langage commun car c’est souvent un écueil majeur à la réussite des projets. Avoir une cartographie claire des différents événements optimise aussi le développement.

Cela permet aussi de figer des limites (les frontières) et mieux cadrer les différents contextes.

Au niveau méthodologique, on commence par monter un atelier collaboratif avec un petit groupe qui mixe les profils techniques ou métiers qui sont impliqués dans le produit (experts du domain, développeurs, architectes).

On commence à cartographier les différentes commandes ou actions en les classant selon un ordre chronologique, ce qui permet de visualiser où commence le processus et où il se termine (cycle de vie). Il n’est pas rare qu’en brainstormant sur un processus en particulier, on en identifie un autre !

Chez Harington, nous maîtrisons cette technique sur le bout des doigts et nous l’avons déjà mise en oeuvre avec des résultats concrets. Contactez-nous, nous viendrons vous présenter nos retours d’expérience clients.

Sources :

https://alexalvess.medium.com/modeling-your-domain-with-event-storming-workshop-3da70c6b35f1

https://blog.flowlab.no/event-storming-fa953f3c62ad