The little Eventmodeling Book

1Event Modeling résout un problème de communication, pas un problème technique

Imaginez la réunion de lancement d'un projet. Les devs parlent d'agrégats (groupes d'objets liés qui changent ensemble comme une seule unité) et d'API. Le chef de produit parle de parcours utilisateur. Le testeur parle de cas d'usage. Personne ne parle de la même chose.

Event Modeling répond à ça. La méthode produit un tableau visuel — une suite de post-its lisible de gauche à droite — que les développeurs, les testeurs et les stakeholders métier peuvent lire sans formation préalable. Dilger formule l'idée ainsi : « une langue universelle qui décrit les besoins de façon si précise que développeurs et métier peuvent tous les deux comprendre ce qu'il faut construire. » (ch. 2)

Pourquoi ça marche : chaque case du tableau est soit un fait concret passé dans le système (un événement, passé immuable), soit une intention (une commande). Ces faits et ces intentions sont compréhensibles par tous, contrairement aux abstractions techniques. Le tableau est la langue commune, et c'est précisément cette langue commune qui manquait dans la plupart des projets IT.

Un point important à connaître dès le départ : Event Modeling ne requiert pas Event Sourcing. Dilger est explicite : « La réponse est clairement non. » (ch. 4) L'Event Sourcing n'est qu'une façon possible d'implémenter un système modélisé avec Event Modeling. Vous pouvez appliquer la méthode à un système legacy CRUD, une base SQL, ou n'importe quoi d'autre — le tableau décrit le flux d'information, pas la technologie de stockage.

2Tout le système se modélise avec seulement trois types de blocs

Voici la liste complète des briques d'Event Modeling. Il y en a exactement trois.

• State Change Slice — l'unique façon d'amener de l'information DANS le système. Un utilisateur clique sur « Valider la commande » → la commande PasserCommande est envoyée → l'événement CommandePassée est enregistré. Toujours dans cet ordre : Source → Command → Event. Un seul Command par Slice, sans exception.
• State View Slice — l'unique façon de SORTIR de l'information du système. L'événement CommandePassée alimente le read model CommandesActives, que l'écran « Mes commandes » affiche. Toujours : Event(s) → Read Model → Screen/Automation.
• Third Party Integration (l'engrenage = Automation) — un appel vers un système externe. L'appel HTTP est dans l'engrenage ; la logique métier reste dans le Command Handler.

Une note sur la Third Party Integration qui surprend souvent : quand vous modélisez un appel d'API externe (par exemple, une passerelle de paiement), l'engrenage appelle l'API externe — mais la commande qu'il déclenche est pour votre système uniquement. La commande ConfirmerPaiement n'est pas « appeler Stripe ». C'est « enregistrer que le paiement a été confirmé », avec le résultat de Stripe déjà dans le payload de la commande. Votre logique métier reste pure ; l'appel externe reste dans l'infrastructure.

Flow complet, avec le paiement Stripe comme exemple.

1. State Change. Écran → commande SoumettrePaiement → événement PaiementSoumis. L'intention est enregistrée. Stripe n'est pas encore appelé : votre système a seulement noté qu'un paiement a été demandé.
2. Automation déclenchée. PaiementSoumis réveille le Process Manager. Le PM porte toute l'infrastructure : il appelle l'endpoint HTTP de Stripe, gère les timeouts et suit le compteur de tentatives dans son état rejoué (état reconstruit en ré-appliquant ses événements passés dans l'ordre — sans requête base de données, sans appel externe).
3. Chemin nominal. Stripe retourne 200. Le PM émet la commande ConfirmerPaiement { stripeChargeId, montant }. Le Command Handler reçoit une commande dont le payload contient déjà le résultat Stripe. Il produit PaiementConfirmé. La logique métier n'a jamais touché Stripe.
4. Chemin de retry. Stripe expire. Le PM relance. Il sait combien de tentatives ont été faites parce qu'il stocke ce compteur dans son propre état interne, reconstruit au redémarrage sans rappeler Stripe. Après trois échecs, il émet AbandonnerPaiement → PaiementÉchoué → flow compensatoire (séquence corrective qui annule ce que les étapes précédentes ont engagé — annuler la commande, notifier l'utilisateur, libérer le stock réservé).

Process Manager ou Saga ? Pour une intégration externe unique, le Process Manager est le bon outil : un orchestrateur stateful (stateful : il conserve un état interne reconstruit par rejeu de ses événements passés, donc il sait toujours où il en est) qui porte l'appel Stripe, porte la logique de retry et rejoue proprement sans re-déclencher d'effets de bord. La Saga — un pattern de chorégraphie où chaque service réagit aux événements de façon autonome, sans coordinateur central — est mieux adaptée quand plusieurs services indépendants doivent se coordonner entre bounded contexts (sous-systèmes distincts avec leur propre modèle de données et vocabulaire, comme Facturation et Livraison) — un service de réservation hôtel et un service de location de voiture, chacun réagissant au même événement sans s'appeler mutuellement. Une API externe : un PM. Plusieurs services : chorégraphie (chaque service écoute l'événement qui le concerne et agit seul, sans chef d'orchestre).

3L'Information Completeness Check : aucune hypothèse laissée invisible

Le scénario classique : vous modélisez un read model « Solde disponible » qui affiche montant – blocages. En implémentation, vous découvrez que blocages n'est stocké dans aucun événement. Deux semaines de rework. Dilger : « La principale raison pour laquelle les projets logiciels prennent du retard, c'est les mauvaises hypothèses sur les données. » (ch. 5)

L'Information Completeness Check force à vérifier, pour chaque attribut d'un read model, que la valeur provient explicitement d'un événement connecté. Pas de flèche = pas de donnée = rouge. L'implémentation ne commence pas tant que tout est vert. La règle s'applique à tous les éléments : commandes, écrans, automations — chaque attribut doit être traçable jusqu'à une source.

Avant de lire la suite : pourquoi est-il important de rendre la source explicite dès la modélisation plutôt qu'à l'implémentation ? Réfléchissez — puis déroulez. Parce que plus on découvre une donnée manquante tard, plus le correctif est coûteux : découverte à la modélisation = quelques minutes pour définir l'événement source ; découverte en sprint review = réécriture du schéma d'événement, du projecteur, et potentiellement de l'IU.

4Frontières d'agrégats et Command Handler pur

Deux règles qui semblent séparées mais partagent la même racine : garder le domaine pur.

Sur les agrégats : « Un agrégat est un périmètre de cohérence. » (ch. 10) Quand une commande touche deux agrégats en même temps, ce sont probablement les frontières qui sont mal tracées — pas la commande. Le test de Dilger : ces deux choses ont-elles vraiment besoin d'être cohérentes au même instant ? Si vous réservez un hôtel et une voiture, la voiture doit-elle être confirmée atomiquement avec l'hôtel ? Presque certainement non. Réservez l'hôtel, puis réservez la voiture ; si la voiture n'est pas disponible, annulez l'hôtel. Deux opérations éventuellement cohérentes. « Il n'existe aucune opération atomique qui dépose de l'argent sur un compte et en retire sur un autre. Ce sont deux opérations éventuellement cohérentes. » (ch. 10)

Sur le Command Handler : un Command Handler prend une liste d'événements passés plus une commande et retourne une liste de nouveaux événements. Rien d'autre. « Aucune dépendance externe, aucun Event Store. » (ch. 6) Pas d'appels HTTP. Pas de lecture en base. Pas besoin de mocks pour tester. « Pour tester un Command Handler, vous n'avez idéalement besoin de mocker quoi que ce soit. » (ch. 6) Le format de test est toujours GIVEN (événements passés = état courant) / WHEN (commande) / THEN (nouveaux événements). Une fonction pure, déterministe, testable en isolation complète.

Le Read Model est le miroir exact. Il prend des événements et retourne une projection — une vue calculée uniquement à partir des événements passés — sans commande, parce qu'un Read Model ne décide rien. Il observe et projette. Le tester utilise GIVEN (événements) / THEN (état du read model). Pas de WHEN.

La symétrie en un coup d'œil :

L'un écrit l'histoire. L'autre la lit.

5Démarrer en 8 étapes — un atelier, un premier flow prêt à implémenter

Les 8 étapes de Dilger pour une équipe qui découvre Event Modeling :

1. Introduction EM — une personne expérimentée explique la méthode (30 min).
2. Brainstorm des événements — tout le monde ensemble liste tous les événements du système. Plus il y a de monde, mieux c'est. Phase chaotique ; l'imparfait est normal.
3. Storyboard — mettre les événements en ordre. Trouver « l'histoire » du système, de gauche à droite.
4. Grouper les événements — identifier les premiers clusters. Pas besoin que ce soit parfait ; ça évoluera.
5. Ajouter les écrans — rendre le modèle visuel, donner un contexte aux événements.
6. Ajouter commandes, read models, automations — sur un groupe à la fois, pas tout le modèle.
7. Définir les swimlanes — premier débat sur les frontières de sous-systèmes et les responsabilités.
8. Modéliser les slices en détail — attributs complets, Given/When/Thens écrits, Information Completeness Check vert.

« Une slice bien faite vaut mieux que quatre à moitié. » (ch. 16) Après l'étape 8, le modèle doit être assez précis pour être implémenté par n'importe qui dans l'équipe sans demander d'explication.

Dilger mappe aussi les slices sur Jira : une slice = un ticket, un chapitre (une flèche bleue regroupant plusieurs slices) = un epic. Les slices progressent de Created → Planned → Assigned → Review → Done. Toute modification d'une slice « Done » est traitée comme une nouvelle slice — elle repasse à Created et repart depuis le début du cycle.