Event-Driven Architecture ou Event Sourcing ?
EDA : une modalité de communication favorisant le découplage des contextes ; ES : un modèle d'écriture dédié à la traçabilité au sein d'un contexte.
Publié le 16 novembre 2022Dernière mise à jour le 1 octobre 2025
Pareil ? Pas pareil ?
Une question d'échelle
Tout est une question d'échelle, voyez plutôt :
- Une Event-driven architecture (EDA) est une modalité de communication entre contextes , à comprendre au sens du Domain-driven design ;
- L'Event Sourcing (ES) est un pattern que l'on retrouve à l'intérieur d'un contexte.
Et rien de plus, fermez le ban 🥁
Non, je vous l'accorde, ça mérite quand-même quelques explications supplémentaires 😁
L'Event-driven architecture : un fonctionnement réactif
Une architecture événementielle, c'est le fait que l'information circule sous forme d'événements métiers, caractérisés par un type (par exemple :
APPOINTMENT_BOOKEDLa beauté de la chose, c'est le découplage :
- Chaque contexte émet des événements sur un bus de données sans se soucier de qui écoutera (broadcast) ;
- La responsabilité du bus est de délivrer les événements à tous les contextes ayant souscrit à ce type d'événement (généralement au travers d'un topic), et rien d'autre. Il n'opère aucune transformation, ne procède à aucun traitement. On parle de dumb pipes, par opposition aux ETL (Extract, Transform, Load) ;
- Les contextes qui écoutent ces événements, quant à eux, ne savent pas quel contexte en est à l'origine.
C'est un fonctionnement réactif : chaque contexte procède à des traitements en réaction à des événements du monde extérieur, émettant d'autres signaux en retour.
Ce fonctionnement est tout à fait singulier : il faut bien comprendre que chaque contexte va accumuler ("sédimenter") de l'information pour pouvoir travailler ultérieurement, lorsqu'il sera interrogé au travers de son API.
Pourquoi est-ce intéressant ? Parce que l'alternative pour un contexte, c'est d'aller chercher l'information quand il en a besoin. Dès lors, si le contexte qui possède l'information n'est pas disponible, l'appelant ne peut pas travailler. Par contraste, une EDA favorise l'autonomie des contextes.
On pourrait en dire beaucoup plus sur le sujet, mais le but est de voir en quoi une telle architecture diffère de l'Event Sourcing, alors parlons d'Event Sourcing.
L'Event Sourcing : un fonctionnement append only
Encore une fois, l'ES est un pattern que l'on retrouve à l'intérieur d'un contexte. Il répond à un besoin bien précis : la traçabilité. La comptabilité et le transport maritime constituent des cas d'école (1).
En comptabilité, si l'on a procédé par erreur à un débit de 100 €, on ne peut pas simplement supprimer l'écriture correspondante, car le risque de falsification des comptes serait trop grand. Pour cette raison, la seule possibilité est de créer un événement "contraire", à savoir une extourne de 100 €.
Ce qui caractérise l'ES, c'est donc une écriture en mode append only. L'ensemble de ces écritures constitue une golden source, à comprendre comme la donnée qu'il faut à tout prix protéger et dont tout se déduit. Elle permet la compréhension de l'état présent du système.
Là encore, on pourrait aller beaucoup plus loin, en parlant de fonctions de décision et d'évolution, puis en montrant pourquoi l'ES appelle souvent le CQRS. Mais ce serait trop pour un seul article.
(1) Voir à ce sujet l'article de Martin Fowler : https://martinfowler.com/eaaDev/EventSourcing.html .