CQRS, ou les deux métiers d'un même modèleCQRS, or the two jobs of one model

Un modèle, deux maîtres. Lire et écrire ne veulent pas la même chose.One model, two masters. Reading and writing don't want the same thing.

Le Repository (#1) a rangé lecture et écriture derrière une frontière — en supposant un seul modèle. Ce numéro questionne ce postulat. Le même Order sert deux besoins de natures opposées : écrire exige un agrégat riche avec ses invariants (on n'expédie que payé), cohérent, modifié une instance à la fois ; lire un tableau de bord exige des lignes plates, dénormalisées, rapides, par milliers, sans aucun comportement. Forcer un seul objet à être bon aux deux, c'est le condamner à être médiocre aux deux. Ce qui varie : la forme que les données doivent prendre selon qu'on décide ou qu'on affiche.The Repository (#1) tucked reads and writes behind a boundary — assuming a single model. This issue questions that. The same Order serves two needs of opposite natures: writing demands a rich aggregate with its invariants (only ship if paid), consistent, modified one instance at a time; reading a dashboard demands flat, denormalized, fast rows, by the thousand, with no behavior at all. Forcing one object to be good at both condemns it to be mediocre at both. What varies: the shape data must take depending on whether you decide or display.

# UN seul modèle Order, tiré par deux besoins opposés
class Order:                       # le modèle d'écriture : invariants, comportement
    def ship(self):
        if self.status != "paid": raise CannotShip()
        self.status = "shipped"

# … et le même Order doit servir le tableau de bord :
def orders_dashboard():
    orders = repo.all()                       # 5000 agrégats Order hydratés…
    return [(o.customer.name, o.total(), o.status, len(o.lines))  # … pour 4 colonnes
            for o in orders]                  # N+1 sur customer, sur lines, lent
# écrire veut un agrégat riche et cohérent ; lire veut des lignes plates et rapides.
# le même objet ne peut pas être bon aux deux à la fois.

L'agrégat gonfle pour l'affichage, et les lectures traînent l'écriture.The aggregate bloats for display, and reads drag the write model.

Forcer un seul modèle a trois coûts qui se renforcent. L'agrégat d'écriture se met à porter des champs d'affichage — un total dénormalisé, le nom du client, un compteur — qui n'ont rien à voir avec ses invariants : la pièce qui doit rester cohérente se charge de choses qui n'engagent aucune règle. Les lectures, elles, paient le prix de la richesse : afficher une liste oblige à hydrater des agrégats entiers, ligne par ligne, avec leurs N+1. Et les deux besoins se disputent à chaque changement : ajouter une colonne au tableau de bord rouvre l'entité métier ; optimiser une requête risque un invariant.Forcing one model has three costs that reinforce each other. The write aggregate starts carrying display fields — a denormalized total, the customer name, a counter — that have nothing to do with its invariants: the piece that must stay consistent gets loaded with things no rule governs. Reads, in turn, pay for richness: showing a list forces hydrating whole aggregates, row by row, with their N+1. And the two needs fight on every change: adding a dashboard column reopens the domain entity; tuning a query risks an invariant.

def orders_dashboard():
    orders = repo.all()                  # 💥 5000 agrégats Order…
    for o in orders:
        o.customer          # … N+1 : une requête par client…
        o.lines             # … N+1 : une requête par lot de lignes…
    return [(o.customer.name, o.total(), o.status) for o in orders]  # 3 colonnes.

On scinde le modèle : une voie pour commander, une voie pour lire.Split the model: one path to command, one path to read.

CQRS trace une ligne entre ce qui change l'état (les commandes) et ce qui le lit (les requêtes). L'animation part du modèle unique écartelé, le sépare en deux — un modèle d'écriture qui garde les invariants, un modèle de lecture plat et libre —, puis montre l'écriture projeter ses changements vers la lecture, et enfin la lecture déménager sur son propre stockage. À chaque marche, le bénéfice grandit ; à la dernière, le prix apparaît : la cohérence à terme.CQRS draws a line between what changes state (commands) and what reads it (queries). The animation starts from the torn single model, splits it in two — a write model keeping the invariants, a flat free read model —, then shows the write side projecting its changes to the read side, and finally the read side moving to its own store. Each step grows the benefit; at the last, the price appears: eventual consistency.

# la voie d'écriture — agrégat riche, invariants (le Repository du #1)
class ShipOrder(repo: OrderRepository):
    def run(order_id):
        order = repo.find(order_id)   # modèle d'écriture▸ à toiyour turn — la voie d'écriture — par où passe la règle, et comment on persiste ?the write path — where does the rule run, and how do you persist? · cliquer pour révélerclick to reveal
# la voie de lecture — modèle plat, zéro comportement, dénormalisé
class OrderSummary:                   # un read model, pas une entité▸ à toiyour turn — le read model — quelle forme ? des champs plats, dénormalisés (customer_name, pas un id à joindre)the read model — what shape? flat, denormalized fields (customer_name, not an id to join) · cliquer pour révélerclick to revealdef dashboard() -> list[OrderSummary]:▸ à toiyour turn — la voie de lecture — elle rend des lignes plates, sans hydrater aucun agrégatthe read path — it returns flat rows, hydrating no aggregate · cliquer pour révélerclick to reveal    # une requête, des lignes plates — n'hydrate aucun agrégat.

Séparer les modèles est presque gratuit. Séparer les stockages se paie en cohérence.Splitting models is nearly free. Splitting stores is paid in consistency.

Le piège n'est pas CQRS — c'est sauter directement à sa forme radicale. On lit « CQRS » et on entend « deux bases de données + un pipeline d'événements », alors qu'on n'a aucune asymétrie de charge à justifier. On hérite immédiatement de la cohérence à terme : un délai entre écrire et voir. Le bug canonique apparaît — l'utilisateur crée quelque chose, est redirigé vers la liste, et ne s'y voit pas, parce que la projection n'a pas encore tourné. On a payé deux stockages et un pipeline pour empirer l'expérience. Bascule le toggle : cherche le moment où écrire et voir cessent d'être atomiques.The trap isn't CQRS — it's jumping straight to its radical form. You read 'CQRS' and hear 'two databases + an event pipeline', when you have no load asymmetry to justify it. You inherit eventual consistency at once: a lag between writing and seeing. The canonical bug appears — the user creates something, is redirected to the list, and doesn't see it there, because the projection hasn't run yet. You paid for two stores and a pipeline to make the experience worse. Flip the toggle: hunt the moment writing and seeing stop being atomic.

# CQRS comme séparation de MODÈLES — une seule base transactionnelle
class ShipOrder(repo):                 # commande : agrégat riche, invariants
    def run(id): o = repo.find(id); o.ship(); repo.save(o)

def order_dashboard():                  # requête : modèle plat, même base
    return db.query("SELECT id, customer_name, total, status FROM order_summary")
    # order_summary est une VUE de la même base → lecture cohérente, immédiate.

# bénéfice : modèle d'écriture propre + lectures taillées, SANS cohérence à terme.
# on déménagera vers un stockage séparé le jour — mesuré — où la charge l'exige.

Un modèle pour tout, ou deux modèles pour deux métiers.One model for everything, or two models for two jobs.

Quand ne pas séparerWhen not to separate

CQRS a un loyer qui grimpe vite avec la radicalité : deux modèles à tenir alignés, et — dès qu'on sépare les stockages — un pipeline de projection et la cohérence à terme. On reste sur un modèle unique — et c'est correct — quand :CQRS has rent that climbs fast with radicality: two models to keep aligned, and — once you split the stores — a projection pipeline and eventual consistency. Stay with a single model — and that's fine — when:

• lire ressemble à écrire : un CRUD où l'on affiche à peu près ce qu'on saisit n'a pas d'asymétrie à exploiter. Deux modèles identiques, c'est de la duplication sans bénéfice — exactement la cérémonie que YAGNI (Vol 0 #3) refuse.reading resembles writing: a CRUD where you display roughly what you enter has no asymmetry to exploit. Two identical models is duplication with no benefit — exactly the ceremony YAGNI (Vol 0 #3) refuses.
• le volume de lecture est calme : si une vue de la même base répond en quelques millisecondes, séparer les stockages n'achète qu'une cohérence à terme dont tu ne veux pas. La séparation des stockages se mérite par une mesure, jamais par anticipation.the read volume is calm: if a view of the same database answers in a few milliseconds, splitting the stores buys only an eventual consistency you don't want. Splitting stores is earned by a measurement, never by anticipation.
• l'utilisateur doit voir son écriture immédiatement : un formulaire qui redirige vers une liste, un panier, un solde — partout où « read-your-own-write » est non négociable, la cohérence à terme est un bug, pas un compromis. Reste cohérent tant que tu peux.the user must see their write immediately: a form redirecting to a list, a cart, a balance — anywhere 'read-your-own-write' is non-negotiable, eventual consistency is a bug, not a tradeoff. Stay consistent as long as you can.

Le réflexe n'est donc pas « fais du CQRS, c'est scalable » ni « n'en fais jamais, c'est compliqué ». C'est : « lire et écrire ont-ils des formes divergentes ? Alors deux modèles. Et seulement si la charge le force, deux stockages — en sachant que je signe alors la cohérence à terme. »So the reflex isn't 'do CQRS, it scales' nor 'never do it, it's complex'. It's: 'do reading and writing have divergent shapes? Then two models. And only if load forces it, two stores — knowing I then sign for eventual consistency.'

Mot de l'éditeurFrom the editor

CQRS souffre d'une réputation que ce numéro voudrait corriger : ce n'est pas « deux bases de données », et ce n'est pas non plus Event Sourcing. C'est, à la racine, l'aveu que lire et écrire sont deux métiers — l'un protège des invariants, l'autre sert de l'information vite — et qu'un seul objet ne peut pas exceller aux deux. La forme la moins chère de cet aveu coûte presque rien : deux modèles, une base, une vue. Tout le reste — projection, stockage séparé, cohérence à terme — n'est qu'une montée graduelle sur un spectre, qu'on gravit une marche à la fois, sous la pression d'une mesure, jamais d'une mode.CQRS suffers from a reputation this issue wants to correct: it's not 'two databases', and it's not Event Sourcing either. At root it's the admission that reading and writing are two jobs — one protects invariants, the other serves information fast — and one object can't excel at both. The cheapest form of that admission costs almost nothing: two models, one store, one view. Everything else — projection, separate store, eventual consistency — is just a gradual climb on a spectrum, taken one step at a time, under the pressure of a measurement, never a fashion.

Le #1 a séparé le métier de sa base ; le #2 a séparé lire d'écrire. Reste une dernière hypothèse à questionner, la plus profonde du volume : on a toujours stocké l'état présent — le statut actuel de la commande. Et si l'on stockait plutôt les faits qui l'ont produit : payée, réservée, expédiée ? L'état devient alors un calcul, pas une donnée. C'est Event Sourcing, le #3 — le pattern le plus séduisant et le plus sur-employé de la série. On y installera le réflexe ET, en grand, le panneau danger.#1 separated the domain from its database; #2 separated reading from writing. One last assumption remains to question, the volume's deepest: we've always stored present state — the order's current status. What if we stored instead the facts that produced it: paid, reserved, shipped? State then becomes a computation, not a datum. That's Event Sourcing, #3 — the series' most seductive and most over-applied pattern. We'll install the reflex AND, in large letters, the danger sign.

Les voisins que ce numéro débloqueThe neighbors this issue unlocks

• Vue matérialiséeMaterialized view — le read model rendu concret par la base elle-même : une requête dont le résultat est stocké et rafraîchi, plutôt que recalculé à chaque lecture. La forme la plus simple d'un modèle de lecture séparé, sans pipeline à écrire — la base s'en charge.the read model made concrete by the database itself: a query whose result is stored and refreshed, rather than recomputed on each read. The simplest form of a separate read model, with no pipeline to write — the database handles it.
• Read replica — le même schéma, répliqué en lecture seule pour absorber la charge des requêtes sans toucher au primaire d'écriture. Le premier cran d'échelle, presque transparent — et la première fois où la cohérence à terme s'invite, par le délai de réplication.the same schema, replicated read-only to absorb query load without touching the write primary. The first scaling notch, nearly transparent — and the first time eventual consistency shows up, via replication lag.
• Event Sourcing — stocker la suite des faits plutôt que l'état courant, et recalculer l'état (ou des read models) en les rejouant. Souvent associé à CQRS, mais bien plus lourd : audit gratuit, migration douloureuse. Le sujet — et l'avertissement — du #3.store the sequence of facts rather than current state, and recompute state (or read models) by replaying them. Often paired with CQRS, but far heavier: free audit, painful migration. The subject — and the warning — of #3.

Le kata — écris-le, ne le relis pasThe kata — write it, don't reread it

# test_order_projection.py — la spec EST le harnais : fais-le passer au vert.
# une voie d'écriture (l'agrégat), une projection qui tient à jour un modèle de
# lecture plat. UNE seule base — pas d'événements, pas de cohérence à terme.

def test_ecrire_projette_une_ligne_plate():
    app = OrderApp()
    app.place_order(id=1, customer="Ada", total=90)
    row = app.dashboard()[0]                        # la lecture ne lit QUE le résumé
    assert row == {"id": 1, "customer_name": "Ada", "total": 90, "status": "pending"}

def test_le_dashboard_n_hydrate_aucun_agregat():
    app = OrderApp()
    app.place_order(id=1, customer="Ada", total=90)
    assert isinstance(app.dashboard()[0], dict)     # des lignes plates, pas des Order

def test_expedier_reprojette_le_statut():
    app = OrderApp()
    app.place_order(id=1, customer="Ada", total=90)
    app.pay(1); app.ship(1)                          # commandes → l'agrégat, invariants
    assert app.dashboard()[0]["status"] == "shipped"  # la projection a suivi

def test_lecture_immediate_read_your_own_write():
    app = OrderApp()
    app.place_order(id=2, customer="Bob", total=10)
    assert any(r["id"] == 2 for r in app.dashboard())  # projection SYNCHRONE : vu aussitôt

def test_ship_refuse_si_pas_paye():
    app = OrderApp()
    app.place_order(id=1, customer="Ada", total=90)
    with raises(CannotShip): app.ship(1)            # l'invariant reste côté écriture

def test_renommer_le_client_rafraichit_toutes_ses_lignes():
    app = OrderApp()
    app.place_order(id=1, customer="Ada", total=90)
    app.place_order(id=2, customer="Ada", total=15)
    app.rename_customer("Ada", "Ada Lovelace")      # le read model est DÉNORMALISÉ…
    names = {r["customer_name"] for r in app.dashboard()}
    assert names == {"Ada Lovelace"}                # …chaque ligne copiée doit être reprojetée,
    # sinon la copie ment. C'est le prix caché d'un modèle de lecture séparé.