Choisir comment persister les données d’une application n’est pas qu’une décision de stockage. Ce choix détermine ce qu’il est possible de reconstituer, la manière d’expliquer les changements et la charge de maintenance du système. L’event sourcing conserve une séquence d’événements comme source de vérité ; un modèle traditionnel stocke généralement l’état en vigueur et, si nécessaire, un historique complémentaire.
Aucune option n’est supérieure dans tous les cas. La vraie question est de savoir quand l’historique complet et la reconstitution apportent assez de valeur pour justifier une architecture plus exigeante. Ce guide propose des critères pratiques pour décider, repérer des solutions plus simples et commencer avec un périmètre maîtrisé.
Ce que signifie l’event sourcing et ce qui le distingue du modèle traditionnel
Avec l’event sourcing, l’application enregistre des faits métier qui se sont déjà produits, tels que CommandeCréée, PaiementConfirmé ou AdresseMiseÀJour. L’état actuel est obtenu en appliquant ces événements dans l’ordre. Au lieu d’écraser une ligne avec la dernière valeur, on conserve une séquence qui décrit l’évolution de l’entité.
Dans un modèle traditionnel, la base de données contient généralement la version en vigueur : par exemple, le statut actuel d’une commande et son montant. Une mise à jour remplace les valeurs précédentes. Si l’on doit savoir qui a modifié une donnée, quand ou quelle était sa valeur antérieure, il est possible d’ajouter un journal d’audit ou un historique dédié.
La différence décisive n’est pas que l’une des approches possède un historique et l’autre non. Elle tient à la source qui fait autorité. Avec l’event sourcing, les événements sont la source de vérité et les vues de l’état actuel en sont dérivées. Dans un modèle traditionnel, l’état persisté fait généralement autorité ; l’historique, lorsqu’il existe, remplit une fonction complémentaire.
Partir du problème, pas de l’architecture
Avant de choisir, précisez quelle question métier vous ne pouvez pas résoudre aujourd’hui. « Nous voulons plus de traçabilité » est trop vague ; « nous devons reconstituer les décisions qui ont produit le solde d’un compte à une date donnée » décrit un besoin vérifiable. Cette précision permet de comparer les solutions sans adopter une architecture pour son seul attrait technique.
- Historique : il faut consulter des changements antérieurs, sans nécessairement reconstituer l’état complet. Un journal d’audit peut suffire.
- Reconstitution : il faut recalculer l’état à partir des faits conservés, par exemple pour corriger une règle métier ou analyser une situation passée.
- Traçabilité : il importe d’expliquer ce qui s’est passé et dans quel ordre. Des événements métier ou un historique conçu à cet effet peuvent répondre au besoin.
- Consultation de l’état actuel : la plupart des écrans doivent uniquement afficher l’état en vigueur. Un modèle traditionnel offre alors un chemin plus direct.
Il est également utile de vérifier si le besoin est permanent et central pour le produit, ou s’il ne concerne qu’un seul processus. L’event sourcing est plus pertinent lorsque la séquence des changements fait partie intégrante du domaine métier, et pas simplement lorsque quelqu’un veut « tout conserver ».
Des critères pratiques pour décider
Évaluez chaque critère à partir d’exemples réels de votre domaine. Ils ne doivent pas tous plaider en faveur de l’event sourcing, mais il faut comprendre quel besoin motive le choix.
- Les changements ont une signification propre : « réservation confirmée » ou « remboursement approuvé » sont des faits importants, et non de simples modifications de champs. Cela plaide pour la modélisation d’événements explicites.
- La reconstitution est nécessaire : l’entreprise doit retrouver des états antérieurs ou les recalculer à l’aide de nouvelles règles. Si elle souhaite seulement afficher les derniers changements, un historique peut suffire.
- L’ordre compte : la séquence des actions détermine le résultat, et l’équipe doit la conserver de manière fiable.
- Plusieurs vues du même processus sont nécessaires : différentes équipes ou fonctions doivent consulter les mêmes faits de façons distinctes. Des projections peuvent répondre à ces besoins de lecture, mais elles impliquent du travail supplémentaire.
- Le domaine comporte des corrections et des exceptions : elles doivent être représentées comme de nouveaux faits — par exemple une correction ou une annulation — sans effacer silencieusement ce qui s’est passé. Il faut définir soigneusement la signification de chaque événement.
Si le besoin se limite à mettre à jour des enregistrements et à consulter leur version en vigueur, le modèle traditionnel sera probablement plus simple. Si l’historique doit être complet, compréhensible et exploitable pour dériver des états, l’event sourcing mérite une évaluation plus approfondie.
Coûts, risques et raisons d’y renoncer
Conserver des événements ne supprime pas la complexité : cela la déplace. Les lectures dépendent souvent de projections, c’est-à-dire de vues dérivées qui sont mises à jour à partir des événements. Si leur traitement est asynchrone, une cohérence éventuelle peut apparaître : pendant un certain temps, une lecture reflète un état antérieur. Le produit doit pouvoir le tolérer ou définir comment présenter et gérer ce délai.
En outre, les événements persistés ne se modifient pas comme de simples lignes. Lorsque le domaine évolue, il faut décider comment interpréter les anciens événements, comment faire évoluer leurs formats et comment reconstruire les projections. Il faut aussi prévoir des procédures pour détecter les échecs de traitement, rejouer les événements lorsque cela ne présente pas de risque et assurer l’exploitation ainsi que le support. Une séquence incomplète ou mal définie peut compromettre précisément la reconstitution recherchée.
Il est préférable d’écarter ou de reporter l’event sourcing si l’équipe ne sait pas expliquer quels événements représentent des faits métier, si les consultations requises sont simples ou si le système n’a pas besoin de reconstituer des états. Autre signal d’alerte : le principal argument est de « disposer d’un audit », sans exigence concernant les consultations historiques, la conservation ou l’utilisation de ces données. Dans ce cas, une table d’historique bien conçue peut atteindre l’objectif avec moins d’éléments.
Exemple hypothétique : commandes, changements et corrections
Imaginons une application de gestion des commandes. L’équipe doit afficher le statut, le montant et l’adresse actuels. Un modèle traditionnel associant les données de la commande à un historique des changements peut suffire si l’objectif est de consulter la version en vigueur et d’expliquer les modifications récentes.
Le choix change si l’entreprise doit reconstituer comment le montant a été calculé, distinguer les confirmations des corrections et recalculer des situations passées en fonction de nouvelles règles. L’event sourcing pourrait enregistrer des faits tels que la création de la commande, la confirmation du paiement et la correction du montant. La vue de la commande serait dérivée de cette séquence. Il faudrait toutefois décider comment représenter une correction, gérer les anciens événements et déterminer quelles lectures risquent d’afficher des données temporairement obsolètes.
Cet exemple ne signifie pas que tous les processus de commande nécessitent l’event sourcing. Le choix dépend de besoins vérifiables : quelle reconstitution est exigée, qui consulte l’historique et quel niveau de complexité l’équipe peut exploiter.
Questions à se poser avant d’adopter l’event sourcing
- Quelle question précise ne peut-on pas résoudre à partir de l’état actuel et d’un historique simple ?
- Quelles entités ou quels processus doivent être reconstitués, et dans quel but métier ?
- Les événements décrivent-ils des faits à la signification stable, ou ne font-ils que reproduire des changements techniques de champs ?
- Quelles vues faut-il maintenir, qui les utilise et quel délai peut être toléré ?
- Comment traiter les corrections, les événements en double, les changements de format et les retraitements ?
- Qui sera chargé de surveiller les projections et de résoudre les échecs de traitement ?
- Existe-t-il une solution plus simple qui satisfait les besoins actuels sans fermer les possibilités futures ?
Commencer sur un périmètre limité et réexaminer le choix
Si les besoins justifient l’event sourcing, limitez son adoption à un processus pour lequel l’historique apporte une valeur claire. Commencez par définir le vocabulaire des événements avec les responsables du domaine et convenez de ce que garantit chaque événement : ce qui s’est produit, les données nécessaires à son interprétation et les éléments qui ne doivent plus changer. Concevez également les principales consultations et la récupération des projections avant d’élargir le périmètre.
Consignez les décisions et réexaminez l’architecture lorsque les besoins évoluent. Si le produit n’exige plus de reconstitution, ou si le coût de maintenance des projections dépasse leur utilité, une simplification peut être raisonnable. Si de nouveaux besoins de traçabilité et d’analyse apparaissent, un historique classique peut ne plus suffire. Le meilleur choix est celui qui répond à des besoins réels et que l’équipe peut exploiter de manière fiable, et non celui qui accumule les mécanismes par anticipation.