CQRS et event sourcing

De la séparation commande-requête à CQRS

L’idée part de peu. Dans Object-Oriented Software Construction (première édition en 1988), Bertrand Meyer a proposé la séparation commande-requête : chaque méthode doit être soit une commande, qui change l’état et ne renvoie rien, soit une requête, qui renvoie une réponse et ne change rien. Poser une question ne devrait jamais changer la réponse. Martin Fowler fait remarquer que la règle admet des exceptions raisonnables (dépiler un élément d’une pile modifie la pile et renvoie l’élément), mais, comme règle par défaut, elle rend le code plus facile à comprendre, car les requêtes peuvent être appelées librement, dans n’importe quel ordre, sans effets de bord.

Vers 2010, Greg Young a étendu le principe des méthodes à des modèles entiers et a appelé le résultat Command Query Responsibility Segregation (CQRS), la séparation des responsabilités entre commandes et requêtes. Au lieu d’un seul modèle objet, et généralement d’un seul ensemble de tables, servant à la fois aux mises à jour et aux lectures, le système dispose d’un modèle d’écriture qui traite les commandes et applique les règles métier, et d’un ou plusieurs modèles de lecture façonnés pour les questions que posent les utilisateurs. L’idée clé est qu’écrire et lire sont deux métiers différents. L’écriture exige des règles strictes, de petites transactions et une structure normalisée, pour qu’un fait soit stocké une seule fois. La lecture exige de la vitesse, des formes dénormalisées qui correspondent aux écrans et aux rapports, et doit souvent absorber bien plus de trafic. Un modèle unique qui essaie de bien faire les deux a tendance à mal faire les deux dès que le domaine devient riche.

Ce que CQRS change concrètement

Côté écriture, une commande comme WithdrawMoney(account 42, £50) arrive à un gestionnaire de commandes (command handler). Le gestionnaire charge l’agrégat concerné (le groupe de données qui doit rester cohérent au sein d’une même transaction, un terme de la conception pilotée par le domaine présenté à la section 5.7), lui demande d’appliquer les règles métier et enregistre le résultat. Les commandes sont des demandes et peuvent être refusées : le compte peut être gelé ou les fonds insuffisants. Côté lecture, une requête comme montre-moi les 30 dernières transactions avec les soldes cumulés reçoit sa réponse d’un modèle de lecture construit exactement pour cet écran, sans jointures, sans logique métier et sans verrous sur les tables d’écriture.

Il faut bien que quelque chose tienne les modèles de lecture à jour. Cette tâche revient à une projection : du code qui écoute les changements côté écriture et met à jour un modèle de lecture. Une projection peut maintenir une table des soldes, une autre un index de recherche des transactions, d’autres encore un document de relevé mensuel et un feature store de scoring de fraude, chacun à partir du même flux de changements. Les modèles de lecture sont donc des données dérivées : on peut toujours les jeter et les reconstruire à partir du côté écriture. C’est cette propriété qui permet d’ajouter sans risque un nouveau modèle de lecture l’an prochain, ou de modifier la forme d’un ancien.

CQRS se décline par degrés, et le degré le plus léger est souvent tout ce dont un système a besoin. Au plus léger, les modèles d’écriture et de lecture sont des classes différentes au-dessus de la même base de données, les lectures étant servies par des vues ou par du code de requête dédié. Au niveau intermédiaire, les modèles de lecture vivent dans des tables séparées, mises à jour dans la même transaction que l’écriture. Au plus lourd, les modèles de lecture vivent dans des stockages différents (un moteur de recherche, une base de données orientée documents, un cache) et sont mis à jour de façon asynchrone à partir d’événements, ce qui apporte scalabilité et flexibilité, mais aussi la cohérence à terme. CQRS n’exige ni event sourcing, ni courtier de messages (message broker), ni microservices ; ce sont des décisions distinctes, souvent prises ensemble, mais pas nécessairement.

Event sourcing : l’état comme suite de faits

La plupart des systèmes stockent l’état courant. Quand Asha retire £120, la ligne de accounts passe de £500 à £380 et l’ancienne valeur disparaît, à moins que quelqu’un n’écrive aussi une ligne d’audit. L’event sourcing, décrit par Martin Fowler en 2005, renverse cette logique : le système stocke chaque changement sous la forme d’un événement immuable dans un journal en ajout seul, et l’état courant est ce que l’on obtient en rejouant les événements dans l’ordre. Les événements sont la source de vérité ; le solde est un calcul.

Les événements sont nommés au passé, car ils enregistrent des faits qui se sont déjà produits et ont été acceptés : AccountOpened, MoneyDeposited, MoneyWithdrawn. Une commande (WithdrawMoney) est une demande qui peut être refusée ; un événement (MoneyWithdrawn) ne peut plus être refusé, seulement compensé par un événement ultérieur. Chaque agrégat a son propre flux d’événements, numéroté à partir de la version 1, et l’event store garantit que les événements d’un flux sont conservés dans l’ordre.

Reconstruire l’état est un pli à gauche (left fold) : partir de rien, appliquer le premier événement, appliquer le deuxième au résultat, et ainsi de suite. La fonction d’application doit être pure et déterministe : elle ne peut appeler ni une horloge, ni un générateur de nombres aléatoires, ni un autre service, car rejouer les mêmes événements doit toujours donner le même état. Toute valeur venue de l’extérieur (un taux de change, un horodatage, un score de fraude) est enregistrée dans l’événement au moment où elle est décidée pour la première fois.

L’écriture suit un cycle fixe. Le gestionnaire de commandes charge le flux, le replie en état courant, exécute la règle métier et ajoute les nouveaux événements avec la version qu’il s’attend à écrire. Si une autre commande a ajouté des événements au même flux entre-temps, l’ajout échoue et le gestionnaire réessaie avec un état à jour. C’est la concurrence optimiste de la section 7.3, appliquée flux par flux, et c’est pourquoi deux retraits simultanés ne peuvent pas dépenser tous deux les mêmes £100.

# A bank account as a stream of events, folded into current state.
# Amounts are in pence so that no floating-point rounding creeps in.
from functools import reduce

events = [
    {"v": 1, "type": "AccountOpened",  "overdraft_limit": 0},
    {"v": 2, "type": "MoneyDeposited", "amount": 50000},
    {"v": 3, "type": "MoneyWithdrawn", "amount": 12000},
    {"v": 4, "type": "MoneyDeposited", "amount": 7550},
    {"v": 5, "type": "MoneyWithdrawn", "amount": 30000},
]

def apply(state, e):                       # pure: old state + event -> new state
    if e["type"] == "AccountOpened":
        return {"balance": 0, "limit": e["overdraft_limit"], "version": e["v"]}
    sign = 1 if e["type"] == "MoneyDeposited" else -1
    return {**state, "balance": state["balance"] + sign * e["amount"], "version": e["v"]}

def decide_withdraw(state, amount):        # command side: check the rule, emit events
    if state["balance"] - amount < -state["limit"]:
        raise ValueError("insufficient funds")
    return [{"v": state["version"] + 1, "type": "MoneyWithdrawn", "amount": amount}]

now = reduce(apply, events, None)          # {'balance': 15550, 'limit': 0, 'version': 5}
as_at_v3 = reduce(apply, events[:3], None) # temporal query: balance 38000

-- An event store can be an ordinary table. The primary key enforces
-- optimistic concurrency: only one writer can append version 6.
CREATE TABLE account_events (
  account_id  uuid        NOT NULL,
  version     integer     NOT NULL,
  event_type  text        NOT NULL,
  data        jsonb       NOT NULL,
  recorded_at timestamptz NOT NULL DEFAULT now(),
  PRIMARY KEY (account_id, version)
);

-- The command handler read the stream up to version 5, decided, and now appends:
INSERT INTO account_events (account_id, version, event_type, data)
VALUES ('2f9c0d6e-4a51-4c7e-9a43-6d1f2b7e8a10', 6, 'MoneyWithdrawn', '{"amount": 2000}');
-- If a concurrent command already appended version 6, this fails with a
-- unique violation; the handler reloads the stream and decides again.

Ce que vous apporte l’event sourcing

Une piste d’audit complète par construction. Dans un système fondé sur l’état, le journal d’audit est une seconde écriture que quelqu’un peut oublier, et il peut contredire les données. Dans un système en event sourcing, le journal est la donnée : il ne peut donc pas diverger. Les régulateurs de la banque, de l’assurance et de la santé y attachent une grande valeur.

Requêtes temporelles. Quel était le solde à 23 h 59 le 31 mars ? ou Quelles commandes étaient au statut PREPARING quand l’écran de la cuisine est tombé en panne ? deviennent des plis sur un préfixe de chaque flux, plutôt qu’un travail d’enquête sur les sauvegardes.

Reconstructions et nouveaux modèles de lecture. Comme les modèles de lecture sont dérivés, une équipe peut corriger un bug dans une projection, supprimer ce qu’elle a produit et rejouer tous les événements pour obtenir une vue corrigée. Elle peut aussi construire un modèle de lecture auquel personne n’avait pensé lors de l’enregistrement des événements, comme un rapport sur la fréquence à laquelle les clients retirent de l’argent liquide dans l’heure qui suit le versement de leur salaire, sur tout l’historique.

Débogage et analyse de scénarios (what-if). Copier un flux dans un environnement de test et le rejouer reproduit exactement l’état qui a causé un bug. Rejouer les mêmes événements avec des règles modifiées montre ce qu’auraient fait les nouvelles règles.

Une source naturelle d’événements d’intégration. Les événements peuvent alimenter d’autres services, même s’il vaut mieux traiter les événements stockés dans un flux comme un détail privé du service propriétaire. Les publier directement couple chaque consommateur au modèle interne ; beaucoup d’équipes les traduisent plutôt en un ensemble plus restreint d’événements d’intégration publics, conçus comme les contrats publiés et durables décrits à la section 6.4.

Snapshots et flux longs

Replier cinq événements est instantané ; replier 400 000 événements pour un compte commerçant très actif à chaque commande ne l’est pas. Un snapshot (instantané) stocke l’état replié d’un flux à une version connue, si bien que le chargement devient lire le dernier snapshot, puis n’appliquer que les événements qui le suivent. Les snapshots sont un cache, pas une source de vérité : ils peuvent être supprimés et recréés à tout moment, en arrière-plan, sans arrêter le système. Prenez-en un tous les N événements ou selon un calendrier, et stockez avec eux la version du code d’application, car un snapshot produit par un ancien code est faux dès que la logique du pli change.

Avant de recourir aux snapshots, vérifiez la conception des flux. Des flux très longs signifient souvent que l’agrégat est trop gros. Un compte bancaire qui vit 40 ans peut être modélisé comme une série de flux plus courts, un par période de relevé, chacun ouvert par un événement BalanceCarriedForward qui enregistre le solde de clôture de la période précédente. Cela reflète la façon dont les comptables clôturent leurs comptes, et cela garde chaque flux assez court pour être chargé rapidement.

Les coûts, en toute honnêteté

Complexité et manque de familiarité. L’event sourcing change la façon dont chaque développeur de l’équipe pense la persistance. Des questions simples comme quels clients habitent à Leeds ? ne peuvent pas du tout être posées à l’event store ; elles exigent une projection. Les outils pour inspecter, migrer et réparer les event stores sont moins matures que pour les tables relationnelles, et moins d’ingénieurs ont fait tourner un tel système en production.

Cohérence à terme des modèles de lecture. Quand les projections s’exécutent de façon asynchrone, un utilisateur peut effectuer un retrait puis voir un solde qui ne l’inclut pas encore. Les parades habituelles consistent à renvoyer la nouvelle version du flux depuis la commande et à laisser le côté lecture attendre que sa projection ait traité cette version (une garantie de lecture de ses propres écritures, comme à la section 7.4) ; à mettre à jour l’interface utilisateur de manière optimiste à partir du résultat de la commande ; ou à mettre à jour les modèles de lecture critiques de façon synchrone, dans la même transaction que l’ajout. Les projections doivent aussi être idempotentes et enregistrer la position qu’elles ont traitée, car des événements peuvent être livrés plus d’une fois après un crash.

Versionnement des événements. Les événements sont stockés pour toujours, si bien que leur schéma ne peut jamais être simplement modifié. Quand MoneyDeposited gagne un champ de devise, des années d’anciens événements ne l’ont toujours pas. Les techniques standard, cataloguées par Greg Young dans Versioning in an Event Sourced System, comprennent les lecteurs tolérants, qui fournissent des valeurs par défaut pour les champs manquants, l’upcasting (une fonction qui convertit une ancienne version d’événement dans la forme actuelle au moment de la lecture, afin que le code du domaine ne voie qu’une seule version), l’introduction d’un nouveau type d’événement à côté de l’ancien et, en dernier recours, la copie d’un flux entier dans un nouveau flux avec des événements transformés. La section 7.7 présente les règles générales de compatibilité.

Supprimer des données personnelles. Un journal immuable se heurte au droit à l’effacement prévu par la législation sur la protection des données. La technique courante est le crypto-shredding (effacement cryptographique) : les champs personnels des événements sont chiffrés avec une clé propre à chaque client, conservée dans un stockage de clés séparé, et l’effacement consiste à détruire cette clé afin que le texte chiffré ne puisse plus être lu. L’autre solution consiste à garder entièrement les données personnelles hors des événements et à ne stocker qu’une référence à un enregistrement qui peut être supprimé. Savoir si la destruction d’une clé vaut effacement relève d’une appréciation juridique plutôt que technique ; convenez donc de l’approche avec le délégué à la protection des données (DPD). La section 8.7 présente les obligations plus larges.

Charge d’exploitation. Reconstruire une projection sur un milliard d’événements peut prendre des heures ; les équipes ont donc besoin d’un moyen d’exécuter la nouvelle projection à côté de l’ancienne et de basculer quand elle a rattrapé son retard. Les event stores croissent sans limite, et le stockage ainsi que les temps de sauvegarde et de relecture croissent avec eux.

Quand n’utiliser ni l’un ni l’autre, et erreurs courantes

Aucun des deux patrons ne convient à un domaine qui consiste surtout en formulaires sur des données (forms over data), à une petite équipe qui construit sa première version, ou à un système dont le seul problème est la charge de lecture (une réplique en lecture ou un cache coûte bien moins cher). L’event sourcing est aussi mal adapté lorsque des données doivent être réellement supprimées à la demande et en grand volume, ou lorsque la plupart des requêtes recoupent de nombreux agrégats, puisque chacune de ces requêtes a besoin de sa propre projection.

Les erreurs courantes sont prévisibles. Les équipes appliquent les patrons à l’ensemble du système au lieu d’un seul contexte. Elles exposent les événements stockés comme contrat public, figeant ainsi leur modèle interne. Elles mettent des valeurs dérivées ou des appels externes dans la fonction d’application, si bien que la relecture donne des réponses différentes. Elles conçoivent les événements comme des blocs génériques AccountUpdated, qui indiquent que quelque chose a changé mais pas ce qui s’est passé ni pourquoi, et perdent l’essentiel de leur valeur. Enfin, elles oublient qu’un modèle de lecture est un cache : elles se mettent à y écrire directement, après quoi il ne peut plus être reconstruit.

Utilisée de façon sélective, la combinaison est puissante. Une plateforme de livraison de repas peut mettre en event sourcing le cycle de vie des commandes (passée, acceptée, en préparation, récupérée, livrée, remboursée), car les litiges et les remboursements exigent l’historique exact, tout en conservant les cartes, les profils de restaurants et les paramètres utilisateur dans des tables ordinaires. Une banque peut mettre en event sourcing le grand livre et les paiements tout en stockant de façon classique les coordonnées des clients, ce qui garde aussi l’essentiel des données personnelles hors du journal immuable.