Conception : Modélisation d’Événements

Qu’est-ce que l’Event Modeling ?

L’Event Modeling est une technique de conception où les événements sont des citoyens de première classe. Plutôt que de penser le système à partir de ses entités, comme cela se fait habituellement, on part du flux d’événements possibles dans l’application. L’idée centrale est que les systèmes sont, en essence, une séquence de faits.

Intéressant. Non ?

Les Trois Blocs de Construction

L’Event Modeling est délibérément simple. Il n’y a que trois éléments fondamentaux :

Événements

Les événements sont des faits — quelque chose qui s’est produit et qui ne peut pas être effacé ou changé. Ce sont des enregistrements du passé, toujours écrits au passé. Exemples : PedidoRealizado, PagamentoConfirmado, QuartoReservado.

Notez que toute action n’est pas un événement. Seules celles qui changent l’état de l’application sont enregistrées. Cela vous rappelle quelque chose ? Si vous êtes attentif, vous vous souviendrez immédiatement de l’Event Sourcing !

Commandes

Les commandes représentent l’intention de l’utilisateur de modifier l’état de l’application. Elles en sont la cause; les événements en sont l’effet. Exemples : RealiserCommande, ConfirmerPaiement, RéserverChambre.

Note : Il est courant d’attribuer à l’acteur du système, à l’utilisateur ou à un processus automatisé, le nom de trigger (déclencheur). Ce déclencheur est, dans certaines sources, illustré comme un quatrième élément. Mais, à des fins générales, considérons pour le moment uniquement les commandes – cela aura plus de sens dans les prochains billets, promis !

Vues (Read Models)

Les vues sont les lectures de l’état actuel de l’application, dérivées des événements accumulés au fil du temps. Elles correspondent à ce que l’utilisateur voit à l’écran, comme le résumé d’une commande ou un rapport.

On les décrit généralement comme les systèmes CRUD qui stockent l’état de l’application. Cependant, dans l’Event Modeling elles constituent un produit et non la principale source de vérité.

Ces trois éléments — événements, commandes et vues — suffisent à modéliser pratiquement n’importe quel système. Simple. Non ?

Les Quatre Schémas

Outre les blocs de construction, l’Event Modeling définit quatre schémas structurels qui décrivent comment ces éléments se combinent :

• Flux principal : une commande est déclenchée, produit un événement, et la vue est mise à jour. Le schéma le plus courant.

• Traduction : des événements externes (provenant d’autres systèmes) sont traduits en événements ayant une signification dans le domaine. Par exemple, des coordonnées GPS converties en HóspedeRetornouAoQuarto.

• Automatisation : des processeurs en arrière-plan réagissent à des événements et déclenchent de nouvelles commandes automatiquement — comme un processeur de paiement qui effectue des prélèvements périodiques.

• Intégration : combinaison des schémas précédents pour gérer des systèmes hérités ou des intégrations complexes.

Le Processus

La mise en œuvre de l’Event Modeling suit un processus collaboratif qui peut être animé lors d’ateliers réunissant des équipes variées — développeurs, experts métiers, designers, etc.

Brainstorming d’Événements

Tous les participants répertorient les événements que le système devrait, selon eux, enregistrer. À ce stade, la règle est de penser librement. Le filtrage vient ensuite.

Ligne du Temps

Les événements sont organisés en ordre chronologique et examinés pour leur cohérence métier. C’est ici que le modèle commence à prendre forme.

Storyboard

Des wireframes ou des maquettes sont insérés dans la ligne du temps, reliant les événements aux écrans de l’application. Chaque champ de l’interface doit avoir une origine claire : d’où vient-il ? Où va-t-il ?

Identification des Commandes

Pour chaque action de l’utilisateur sur les écrans, une commande est identifiée et associée à l’événement qu’elle génère. Les entrées de l’application deviennent explicites. Sont aussi prises en compte les commandes générées par des processus automatiques comme vu dans Automatisation.

Identification des Vues

Pour chaque écran affichant des données, une vue est identifiée et associée aux événements qui l’alimentent. Les sorties de l’application deviennent explicites.

Appliquer la Loi de Conway

Les événements sont regroupés en couloirs (swimlanes) qui représentent des composants autonomes. Chaque couloir peut appartenir à une équipe différente, avec sa propre responsabilité et son cycle de livraison. Vous vous souvenez des Contextes Délimités du DDD et de la Loi de Conway ? Oui ! Ici, ils sont conçus de manière intentionnelle.

Élaborer les Scénarios

Enfin, les spécifications sont élaborées en utilisant le langage Gherkin (Given-When-Then) et créées pour chaque commande et vue. Exemple :

« Étant donné que le client est enregistré et dispose d’un moyen de paiement enregistré, lorsqu’il tente de réserver une chambre, alors une réservation est créée. »

Ces spécifications remplacent les histoires d’utilisateur isolées, les reliant directement au modèle.

Pourquoi utiliser l’Event Modeling ?

En plus de rendre le design plus clair et collaboratif, l’Event Modeling apporte des bénéfices pratiques pour la gestion du projet :

• Estimations sans spéculation : l’effort requis pour chaque étape du flux peut être mesuré empiriquement, rendant la planification plus prévisible.

• Changements sans surprises : réorganiser ou ajouter des fonctionnalités a un coût clair et maîtrisé.

• Sécurité par design : le modèle rend évident où et quand des données sensibles traversent les frontières de l’application, facilitant les audits.

• Parallélisme réel : comme les contrats entre les étapes sont explicites, des équipes différentes peuvent travailler en parallèle avec un couplage minimal.

Conclusion

L’Event Modeling est une technique puissante précisément parce qu’elle est simple. Avec seulement trois éléments et quatre schémas, il est possible de modéliser des systèmes complexes de manière à ce que toutes les personnes impliquées — techniques ou non — puissent comprendre et contribuer.

Je recommande, comme dans l’article sur l’Event Sourcing, la lecture du livre Understanding EventSourcing (en anglais), de Martin Dilger, qui aborde le sujet avec une profondeur accrue.

Grâce à cet article, il est possible de comprendre, de manière introductive, comment fonctionne l’Event Modeling. Si vous avez déjà eu un contact avec la technique, toutefois, vous pourriez ressentir l’absence du diagramme des événements. C’est volontaire. L’idée est de fixer les concepts et, dans le prochain billet, d’illustrer une application d’exemple – dont le code sera mis à disposition à la fin de la série.