CQRS et event sourcing : deux choix à faire séparément

Vous pouvez séparer les commandes des lectures tout en conservant l'état courant dans une base classique. Vous pouvez aussi choisir de reconstruire cet état à partir d'événements enregistrés. CQRS concerne la première séparation ; l'event sourcing concerne la façon de conserver la référence. Les deux se combinent souvent, mais répondent à des besoins différents.

CQRS organise les modèles de l'application

Le modèle de commande applique les règles lorsqu'un utilisateur demande un changement. Le modèle de lecture prépare les informations attendues par les écrans ou les autres consommateurs. C'est la séparation décrite dans l'article consacré à CQRS.

Ce choix n'impose ni deux bases de données ni un journal d'événements. Les deux modèles peuvent partager une base qui conserve simplement la dernière version des données.

L'event sourcing conserve les faits qui expliquent l'état

Prenons un panier. Un stockage classique conserve son contenu actuel : deux livres et un carnet. Un stockage fondé sur les événements peut conserver les faits successifs : livre ajouté, carnet ajouté, second livre ajouté.

En appliquant ces événements dans l'ordre prévu, le système retrouve le contenu du panier. Le journal constitue alors la référence permettant de reconstruire l'état.

Publier un événement après une modification ne suffit donc pas à faire de l'event sourcing. Dans de nombreuses applications, les événements servent seulement à prévenir d'autres composants ; l'état enregistré dans les tables reste la référence.

Pourquoi les deux approches sont souvent associées

Un journal permet de comprendre l'histoire d'un objet, mais il répond moins directement à une question comme « quels clients ont une commande en attente ? ». Des projections peuvent préparer cette réponse dans un format adapté.

Cette combinaison conduit naturellement à séparer la décision, fondée sur les événements, des vues de lecture. Elle explique la proximité fréquente entre CQRS et event sourcing, sans en faire une obligation.

Greg Young souligne les bénéfices de leur association. D'autres auteurs, dont Martin Fowler, insistent sur la complexité que ces choix peuvent ajouter. Il faut comparer ces coûts avec les difficultés concrètes de l'application.

Préciser le besoin d'historique

Le journal peut être utile pour comprendre une succession de décisions, recalculer des résultats avec de nouvelles règles ou reconstituer un état passé. Ces besoins doivent être définis précisément : quelles informations faut-il retrouver, à quelle date et avec quel niveau de preuve ?

L'event sourcing n'est pas la seule manière de conserver un historique. Des tables temporelles, un journal d'audit ou des versions de documents peuvent répondre à certains besoins. La différence est que, dans l'event sourcing, les événements portent la référence utilisée pour reconstruire l'état métier.

Anticiper le coût du journal

Les événements sont conservés longtemps, tandis que le code et le métier évoluent. Il faut donc prévoir leur compatibilité, leur interprétation et les corrections de données.

Le rejeu demande aussi de l'attention. Reconstruire un état ne doit pas renvoyer les courriels ou répéter les paiements réalisés dans le passé. Les effets externes doivent être distingués du calcul de l'état.

Des instantanés peuvent accélérer la reconstruction d'un historique long. Ils ajoutent un mécanisme à maintenir et ne dispensent pas de vérifier que la source permet bien de retrouver le résultat attendu.

Choisir à l'échelle du domaine concerné

Un produit peut utiliser CQRS pour une gestion de stock soumise à de nombreuses décisions concurrentes, et garder un modèle commun pour des préférences simples. La concurrence seule ne rend pas CQRS indispensable ; elle peut en rendre la séparation utile.

De même, un domaine peut avoir besoin d'un historique métier complet tandis qu'un autre se satisfait de l'état courant. Il n'est pas nécessaire d'appliquer la même solution partout.

Commencez par deux questions : les commandes et les lectures ont-elles des besoins suffisamment différents pour séparer leurs modèles ? Puis, le journal d'événements apporte-t-il une capacité dont le métier a réellement besoin ? Les réponses permettent de choisir chaque mécanisme pour son utilité propre.

Sources

• G. Young, CQRS, Task Based UIs, Event Sourcing agh!, 16 février 2010.
• G. Young, CQRS Documents, novembre 2010.
• M. Fowler, Event Sourcing, 2005.
• M. Fowler, CQRS, 2011.
• U. Dahan, Clarified CQRS, 2009.
• O. Dudycz, CQRS facts and myths explained, mars 2021.
• Cosmic Python.