CQRS et Event Sourcing : deux idées qu'on confond tout le temps

On les cite toujours ensemble, au point de croire que l'un implique l'autre. C'est faux, et cette confusion est la première source de projets qui s'effondrent sous leur propre poids.

Tu as sûrement déjà entendu la formule « on fait du CQRS avec de l'Event Sourcing », lâchée comme si c'était un seul et même choix. C'est le malentendu fondateur, et le dissiper est la première chose utile que ce cours puisse faire pour toi. Ce sont deux idées indépendantes, qu'on peut adopter séparément.

Les quatre combinaisons existent, et trois d'entre elles sont parfaitement légitimes :

Ce cours prolonge la série DDD. Tu y retrouveras les agrégats (ce qui émet les événements), les domain events (ce qu'on stocke), et le change-tracking par événements qu'on avait déjà entrevu. On file un seul exemple du début à la fin : un compte bancaire, le cas d'école de l'Event Sourcing.

CQRS : lire et écrire ne sont pas le même métier

Un même modèle qui sert à la fois à valider une opération et à alimenter trente écrans finit tiraillé entre deux besoins contradictoires. CQRS tranche : on arrête de vouloir un modèle unique.

Reprends le compte bancaire. Quand tu écris — un retrait — ce qui compte, c'est la règle : « pas de découvert au-delà de l'autorisation ». Tu as besoin d'un modèle riche, qui protège cet invariant, qui refuse l'opération illégale. Quand tu lis — afficher le solde, l'historique, un relevé PDF, un graphique de dépenses — tu te fiches des règles : tu veux des données, vite, dans la forme exacte de l'écran.

Ces deux besoins tirent un modèle unique dans des directions opposées. Le modèle d'écriture veut être normalisé, encapsulé, avare en accès. Le modèle de lecture veut être dénormalisé, plat, taillé pour chaque vue. Vouloir les servir tous les deux avec les mêmes classes, c'est le compromis permanent — et médiocre des deux côtés.

Une fois les deux côtés séparés, chacun peut évoluer selon ses propres contraintes. Le côté écriture reste un agrégat DDD soigné, gardien de ses invariants. Le côté lecture devient une collection de modèles de lecture (read models) : autant de vues dénormalisées que d'écrans, chacune optimisée pour sa requête, sans la moindre logique métier.

C'est exactement le principe qu'on avait esquissé dans le cours repositories & factories : « un repository ne sert pas à lire pour afficher ». Le côté commande passe par les agrégats et leurs repositories ; le côté requête passe par des read models dédiés. CQRS, c'est ce principe, nommé et assumé.

Deux flux : la commande qui décide, la requête qui renseigne

Concrètement, à quoi ressemblent ces deux côtés dans le code ? À deux chemins qui ne se croisent presque jamais, avec deux vocabulaires distincts.

Le côté écriture s'articule autour de la commande : une intention exprimée par l'utilisateur, formulée à l'impératif. « Retire 20 € du compte. » Une commande n'est pas une donnée, c'est une demande d'action qui peut être refusée si elle viole une règle.

// Une commande : une intention, immuable, nommée à l'impératif.
final readonly class WithdrawMoney
{
    public function __construct(
        public string $accountId,
        public int    $amount,   // en centimes
    ) {}
}

// Son handler : charge l'agrégat, applique la règle, sauvegarde. Ne retourne rien d'utile.
final class WithdrawMoneyHandler
{
    public function __invoke(WithdrawMoney $command): void
    {
        $account = $this->accounts->get(new AccountId($command->accountId));
        $account->withdraw($command->amount);   // l'agrégat protège l'invariant de découvert
        $this->accounts->save($account);
    }
}

Le mot handler ici n'a rien de spécifique à un projet : c'est le vocabulaire officiel des bus de messages, comme Symfony Messenger. Un bus de commandes reçoit la commande et la route vers son unique handler. Rien ne t'oblige à utiliser un bus, cela dit — un simple appel de service fait aussi l'affaire ; le bus apporte surtout un point d'entrée uniforme et des middlewares (transaction, validation, journalisation).

Le côté lecture, lui, s'articule autour de la requête : une question, sans le moindre effet de bord. « Quel est le solde du compte ? » Le handler de requête va chercher dans un read model taillé pour la réponse, et ne touche jamais à un agrégat.

// Une requête : une question. Son handler lit un read model, ne modifie rien.
final class GetAccountBalanceHandler
{
    public function __invoke(GetAccountBalance $query): BalanceView
    {
        return $this->readDb->fetchBalanceView($query->accountId);  // données plates, prêtes à afficher
    }
}

CQRS tout seul : trois degrés de séparation

Avant de plonger dans les événements, arrêtons-nous : la plupart des bénéfices de CQRS s'obtiennent sans jamais stocker un seul événement. Il suffit de choisir jusqu'où pousser la séparation.

La grande erreur, c'est de croire qu'il faut « tout ou rien ». CQRS se décline en degrés, du plus léger au plus engageant, et tu peux t'arrêter à celui qui sert ton besoin. Voici les trois paliers, sur une seule base de données classique.

Le point crucial : jusqu'au palier 2, tout reste synchrone et fortement cohérent. Une lecture juste après une écriture voit la nouvelle valeur. On profite de la clarté de CQRS sans le casse-tête de la cohérence différée. Une écrasante majorité d'applications n'a jamais besoin d'aller au-delà.

Tout ce qu'on vient de voir tient sans Event Sourcing. Le read model du palier 3 peut être alimenté par de simples domain events émis à l'écriture, sans jamais faire de l'état stocké un log d'événements. C'est maintenant, seulement, qu'on ouvre l'autre grande idée : et si on ne stockait que les événements ?

Event Sourcing : stocker l'histoire, pas le solde

Ta banque ne stocke pas « tu as 340 € » et rien d'autre. Elle stocke chaque opération, et le solde n'est que leur somme. C'est exactement ça, l'Event Sourcing.

Ouvre ton relevé bancaire. Que vois-tu ? Pas une ligne unique « solde : 340 € », mais une suite d'opérations : dépôt de 500, retrait de 60, paiement de 100, retrait de 20… Le solde, lui, n'est écrit nulle part comme une vérité première — il se déduit de la somme des opérations. Ta banque fait de l'Event Sourcing depuis des siècles.

Compare les deux approches sur notre compte. En stockage classique, une colonne balance qu'on écrase à chaque opération. En Event Sourcing, une table d'événements où l'on ne fait qu'ajouter :

// Chaque événement est un fait passé, immuable, nommé au passé composé.
MoneyDeposited  { amount: 500 }
MoneyWithdrawn  { amount:  60 }
MoneyWithdrawn  { amount: 100 }
// solde = 500 - 60 - 100 = 340  (calculé, jamais stocké tel quel)

Ce simple renversement change tout. Tu ne perds plus jamais d'information : le « pourquoi » du solde est là, gravé. Tu peux répondre à des questions qu'on ne t'avait pas encore posées (« combien de retraits en mars ? »), auditer sans effort, et même remonter le temps pour connaître l'état à n'importe quelle date. Un état stocké classiquement, lui, a oublié tout ce qui l'a précédé.

Le simulateur ci-dessous te fait vivre la différence. Choisis un mode de stockage, effectue des opérations, puis pose la question qui tue : « d'où vient ce solde ? ». Un seul des deux modes saura répondre.

Reconstruire l'agrégat en rejouant son histoire

Si l'état n'est plus stocké, comment charge-t-on un compte pour lui appliquer une nouvelle opération ? On le fait renaître de ses événements — un pliage de son histoire.

Le cours repositories & factories distinguait créer un objet et le reconstituer depuis la persistance. L'Event Sourcing pousse la reconstitution à sa forme la plus pure : on ne recharge pas un état figé, on rejoue les événements pour le reconstruire.

Concrètement, l'agrégat sait appliquer chaque type d'événement à son propre état — une méthode par événement, qui ne fait que muter des champs, sans aucune règle. Les règles, elles, vivent dans les méthodes de commande.

final class Account
{
    private int $balance = 0;

    // Reconstitution : on plie la liste d'événements sur un objet neuf.
    public static function replay(array $events): self
    {
        $account = new self();
        foreach ($events as $event) {
            $account->apply($event);   // aucune règle ici : juste avancer l'état
        }
        return $account;
    }

    private function apply(object $e): void
    {
        match ($e::class) {
            MoneyDeposited::class => $this->balance += $e->amount,
            MoneyWithdrawn::class => $this->balance -= $e->amount,
        };
    }

    // Une commande : ici vivent les RÈGLES. Elle ne mute pas directement — elle émet un événement.
    public function withdraw(int $amount): void
    {
        if ($amount > $this->balance) {
            throw new InsufficientFundsException($this->balance, $amount);
        }
        $this->recordThat(new MoneyWithdrawn($amount));  // l'événement, puis apply()
    }
}

Note la séparation nette, propre à l'Event Sourcing : la méthode de commande withdraw() décide (elle vérifie la règle et refuse le découvert), tandis que la méthode apply() enregistre le fait (elle avance l'état, sans jamais juger). Une commande acceptée produit un événement ; cet événement est appliqué à l'état, puis ajouté au journal au moment du save.

Une inquiétude légitime surgit ici : rejouer tous les événements à chaque chargement, pour un compte ouvert depuis dix ans, ça fait beaucoup. C'est vrai, et c'est le problème que les snapshots résoudront (section 08). Mais d'abord, réglons la question du côté lecture : comment ces événements alimentent-ils les écrans ?

Les projections : des événements aux écrans

Rejouer l'histoire à chaque affichage serait absurde. On pré-calcule des vues en écoutant le flux d'événements. Mais ces vues arrivent avec un léger retard — et ce retard a un nom.

On ne va évidemment pas rejouer dix ans d'opérations chaque fois qu'un client rafraîchit sa page de solde. Le côté lecture de CQRS reprend ici tout son sens : on maintient des projections, des read models pré-calculés qui écoutent le flux d'événements et se tiennent prêts à répondre instantanément.

La beauté, c'est qu'un même journal peut nourrir autant de projections que tu veux, chacune taillée pour un besoin : une pour le solde, une pour l'historique paginé, une pour un tableau de dépenses par catégorie, une pour un moteur de recherche. Elles sont toutes dérivées de la même source de vérité, sans jamais la modifier.

Mais dès que la projection tourne après l'écriture — de façon asynchrone, dans un worker — un décalage apparaît. Entre le moment où l'événement est écrit dans le journal et le moment où la projection l'a traité, le read model est en retard. C'est la fameuse cohérence eventual.

Le piège classique, c'est le « read-your-writes » : l'utilisateur fait un dépôt, l'écran se rafraîchit aussitôt, et affiche encore l'ancien solde parce que la projection n'a pas rattrapé. Le simulateur ci-dessous te fait sentir ce décalage — et pourquoi il faut le concevoir, pas le subir.

Le superpouvoir : reconstruire et inventer des vues rétroactivement

Comme tout est dans le journal, tu peux jeter une projection et la reconstruire à l'identique. Mieux : tu peux créer aujourd'hui une vue qui répond à une question d'hier.

Voici le bénéfice qui, à lui seul, justifie parfois l'Event Sourcing. Puisque le journal d'événements est la source de vérité et que les projections n'en sont que des dérivés, une projection devient jetable et reconstructible. Un read model corrompu ? On le vide et on rejoue le journal. Il repart neuf, exact.

Mais le vrai coup de génie va plus loin. Le jour où le métier te demande une statistique à laquelle personne n'avait pensé — « combien de retraits par mois depuis l'ouverture ? » — tu n'es pas condamné à ne compter qu'à partir d'aujourd'hui. Tu écris une nouvelle projection, tu rejoues tout l'historique, et la voilà remplie comme si elle avait toujours existé.

Le simulateur illustre cet écart de manière frappante. On a un historique d'opérations. Le métier réclame une nouvelle stat aujourd'hui. Selon le mode de stockage, tu peux remonter le temps — ou tu pars de zéro.

Snapshots : quand rejouer dix ans devient trop long

Reconstruire un agrégat en rejouant chaque événement est élégant — jusqu'à ce que le journal compte des dizaines de milliers d'entrées. Le remède est simple : une photo, prise de temps en temps.

Le rejeu intégral (section 05) a une limite évidente. Un agrégat très actif — un compte de trading, un panier géant, un jeu — peut accumuler des dizaines de milliers d'événements. Les rejouer tous à chaque chargement finit par coûter cher. La réponse canonique porte un nom photographique.

Le point essentiel — et souvent mal compris — c'est qu'un snapshot est une optimisation, pas une source de vérité. Le journal reste la vérité ; le snapshot n'est qu'un raccourci qu'on peut jeter et régénérer. Si un snapshot est corrompu ou si la logique change, on le supprime et on rejoue depuis le journal. On ne « répare » jamais un snapshot à la main.

Au-delà des snapshots, la performance de l'Event Sourcing repose sur une asymétrie confortable : les écritures sont des ajouts (append-only), l'opération la plus rapide qu'une base sache faire — pas de verrou de mise à jour, pas de contention sur des lignes existantes. Et les lectures passent par les projections, déjà pré-calculées. Chaque côté est optimisé pour ce qu'il fait, ce qui nous ramène, encore une fois, à la séparation CQRS.

Reste une garantie à assurer côté écriture : deux commandes concurrentes sur le même agrégat ne doivent pas produire deux séries d'événements incohérentes. On s'appuie pour cela sur le verrou optimiste par version — exactement le mécanisme vu dans les cours agrégats et transactions SQL : on n'ajoute des événements que si la version attendue du flux n'a pas bougé entre-temps.

Les pièges : ce dont personne ne te prévient

L'Event Sourcing brille dans les slides. En production, il présente une facture bien réelle : cohérence différée, événements qu'on ne peut plus modifier, et un droit à l'oubli qui se heurte à un journal immuable.

Tout ce qui précède est séduisant. Il serait malhonnête de s'arrêter là : l'Event Sourcing a des coûts spécifiques, et les ignorer mène à des projets qui regrettent amèrement leur choix. Voici les quatre murs contre lesquels on se cogne.

La bonne nouvelle, c'est que ces pièges sont surtout ceux de l'Event Sourcing. CQRS seul — jusqu'au palier 2, synchrone — n'en subit presque aucun. C'est une raison de plus d'adopter les deux idées séparément, et dans le bon ordre.

Synthèse : séparer, puis peut-être sourcer

Deux idées, un ordre d'adoption, et une question à te poser honnêtement avant de te lancer : mon domaine mérite-t-il vraiment tout ça ?

Récapitulons le cheminement. CQRS sépare le modèle qui écrit du modèle qui lit — une idée simple, applicable graduellement, dont l'essentiel des bénéfices s'obtient sans jamais quitter le confort de la cohérence forte. L'Event Sourcing, lui, remplace l'état stocké par un journal d'événements dont l'état n'est qu'un dérivé — une idée puissante, qui débloque l'audit, l'historique et les projections rétroactives, au prix d'une vraie complexité.

L'arbre de décision

Où ça se relie