CQRS

CQRS (Command Query Responsibility Segregation) uses separate models for writing and for reading, rather than one model serving both. It earns its complexity only when the read and write sides genuinely diverge; for most aggregates a single model is simpler and correct.

It is genuinely post-Evans. Greg Young named and shaped the pattern from his ~2007 “DDDD” talks, and it solidified around 2009 to 2013 (the CQRS Documents, Fowler’s CQRS bliki, Vernon’s Implementing Domain-Driven Design). It is not the same as a domain event or event sourcing. The three are distinct patterns with a one-way dependency, frequently sold together as “DDD plus CQRS plus event sourcing” but held as a bundle by none of the field’s authorities. The dependency is asymmetric: CQRS stands alone without event sourcing, but event sourcing effectively requires CQRS. As Young puts it, “you can use CQRS without Event Sourcing but with Event Sourcing you must use CQRS”: an append-only event log cannot answer ad-hoc queries, so it forces a separate read model.

Signal: your read model answers queries the write model would struggle with, and the two can change shape independently. If they still mirror each other, you do not need it yet. Part of Domain-Driven Design.

Sources

• Greg Young, CQRS and Event Sourcing (Code on the Beach 2014): the source of “you can use CQRS without Event Sourcing but with Event Sourcing you must use CQRS”.
• Greg Young, CQRS Documents (2010): the 2010-era write-up where the pattern solidified, and where CQRS and event sourcing are called a “symbiotic relationship”.
• Martin Fowler, CQRS: the bliki entry that catalogs the pattern and its costs.