CodeParkCQRS (Command Query Responsibility Segregation) uses one model for commands (writes) and a separate model for queries (reads). The read side can be denormalised views or a different store built for the queries, such as a search index. Denormalised means data is copied and pre-joined so reads are fast. The write side updates the read side, usually asynchronously. So the read side is eventually consistent: it can be a little behind for a short time.
Event sourcing stores an entity's state as an append-only list of events (OrderPlaced, ItemAdded) instead of only the current row. Append-only means you only add events and never change old ones. The system rebuilds the current state by replaying the events. Snapshots (saved copies of the state at a point in time) make this faster. You get a full audit trail, and you can build new read models from the history.
Teams often use the two together, but each one works alone. Both add real complexity:
- You must version the event schema as events change over time.
- The UI must handle eventual consistency.
- Debugging is harder.
They pay off for complex domains with strong audit needs, or with very different read and write loads. They do not pay off for typical CRUD apps. Martin Fowler warns that CQRS is risky for most systems.
- CQRS uses separate models for writes and reads.
- Read models are often eventually consistent, so they can be briefly behind.
- Event sourcing stores state as an append-only log of events.
- Event sourcing gives an audit trail, replay and new projections, and snapshots make rebuilding faster.
- Both add high complexity, so use them only for complex or audit-heavy domains.