CQRS — Quick Reference

Quand utiliser

Architecture en 30 secondes

[ User ]
   ↓
[ Command ]──────────▶ [ Write Model (Domain) ]
                              ↓ persist + emit
                       [ Event(s) ]
                              ↓
[ Query ] ◀───── [ Read Model (denormalised) ] ◀── projections

• Command side : modèle normalisé, focus invariants métier. Écrit, ne lit que ce qui est nécessaire à la validation.
• Query side : modèle dénormalisé, focus performance lecture. N'a pas de logique métier.
• Projections : transforment les events en read models. Eventually consistent.

Trade-off central

Patterns associés (souvent ensemble)

• Event Sourcing : stocker la séquence d'events comme source de vérité, le write model est reconstruit en replay.
• Saga / Process Manager : orchestrer des transactions distribuées via events.
• Outbox Pattern : garantir l'atomicité publication event + write DB.
• Materialized Views : projections persistées en table dédiée pour query speed.

Anti-patterns critiques

• ❌ CQRS sans cas d'usage clair → over-engineering, double charge cognitive.
• ❌ Read model qui exécute des règles métier → bug d'invariants à chaque projection.
• ❌ Projections synchrones → on perd le bénéfice scalability.
• ❌ Event Sourcing sans snapshots → replay de millions d'events au boot.
• ❌ Command qui retourne data complète → c'est une Query déguisée.

Pour aller plus loin

Implémentations Symfony / Laravel / .NET, Event Sourcing (Prooph, EventStoreDB), saga patterns, outbox, exemples concrets, migration progressive d'un CRUD vers CQRS, checklists par phase : voir

@.claude/skills/cqrs/REFERENCE.md

.