CQRS Explained: It's Just Two Models, Not a Whole Architecture

CQRS — Command Query Responsibility Segregation — is Greg Young's 2010 extension of Bertrand Meyer's method-level CQS to the model level. The entire pattern: use a separate model for writes (commands) and reads (queries). That's it. Not event sourcing, not a message bus, not two databases.

The implementation spectrum runs from splitting methods on one service class (free) through separate DTOs and materialized views (cheap) up to fully async separate read databases synced via events (expensive). Most apps should stay at tier 2 or 3. Tier 4 introduces eventual consistency and the read-your-own-writes problem, solvable via route-to-primary, version tokens, or optimistic UI merge.

The honest default: don't use CQRS. Start with a single model and introduce separation only when read/write shapes genuinely diverge and you feel the pain. Fowler himself warns that the majority of CQRS adoptions he's seen caused more harm than good.