CQRS Without the Cargo Cult
Separating reads from writes solves a real problem. Most teams adopt the folder structure and none of the benefit.
CQRS is a genuinely useful idea wearing a very intimidating name. At its core it says: the shape of the data you write is rarely the shape you want to read, so stop forcing one model to do both jobs.
The problem it actually solves
A write model cares about invariants — this order cannot ship twice, this balance cannot go negative. A read model cares about the screen — this dashboard needs twelve fields from six tables, fast. Optimising one usually damages the other.
What most teams implement instead
- A Commands folder and a Queries folder, both hitting the same ORM the same way
- A mediator library, because every tutorial used one
- Event sourcing bolted on, because the diagrams appeared together
None of that is CQRS. It is the file layout of CQRS with the costs of CQRS and none of the separation that pays for it.
Adopt the split when reads and writes have genuinely different needs. Until then, one model is not technical debt — it is proportionate.
And when you do split, be explicit about consistency. The moment your read model is built asynchronously, someone will refresh a page and see their own change missing. That is a product conversation, not an implementation detail.
- #CQRS
- #Patterns
- #Scaling