mcpField
C
cqrs

cqrs

github.com/thebeardedbearsasDevelopment107114 installsUpdated today
Repository

About cqrs

A CQRS reference skill explaining when to separate write and read models, how the architecture works, and its trade-offs. It helps developers assess adoption and avoid common design pitfalls.

Key features

  1. 01Guidance on when CQRS fits
  2. 02Command and query model overview
  3. 03Trade-offs and consistency considerations
  4. 04Related patterns and anti-patterns

Use cases

  1. 01Assess CQRS for a complex business domain
  2. 02Plan separate read and write scaling
  3. 03Review event-driven architecture choices
  4. 04Identify CQRS design pitfalls

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/thebeardedbearsas/claude-craft --skill cqrs

After installing, type/cqrsin Claude Code to confirm it loaded.

Bundled filesREFERENCE.md

Details

From the project README

CQRS — Quick Reference

CQRS (Command Query Responsibility Segregation) sépare les opérations d'écriture et de lecture dans des modèles distincts. N'est pas par défaut — c'est une optimisation à activer quand le coût de la complexité est justifié.

Quand utiliser

PertinentPas pertinent
Domaine métier complexe avec règles d'invariants richesCRUD simple, domaine pauvre
Ratio lectures/écritures > 10×Petits projets, équipe junior
Audit / compliance (Event Sourcing naturel)Cohérence immédiate requise
Read models hétérogènes (mobile vs analytics vs back-office)Modèle de données stable et unique
Scale différencié reads vs writes (replicas, cache, search)Charge faible, monolithe modeste

Règle d'or : commencer par une architecture classique. Migrer vers CQRS lorsqu'au moins 2 des cas pertinents sont présents simultanément.

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

BénéficeCoût
Scale indépendant lecture / écritureEventual consistency (≈ 50-500 ms latency typique)
Read models taillés pour chaque besoinPlus de code à maintenir (2 modèles)
Event Sourcing devient facile à brancherDebugging plus complexe (event flow)
Audit trail naturelMigration tardive très coûteuse

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.

Comments

Markdown supported