CQRS separates command decisions from query views. The hard part is not the split; it is reliable synchronization from writes to reads.
Reasoning Chain
-
Commands change business facts, not just tables.
-
Read models need derived state that often cannot be reconstructed safely from row triggers alone.
-
Polling creates latency, missed intent, ordering ambiguity, and scaling pressure.
-
Updating the write store and read store in one use case creates a double-commit problem.
-
Durable domain events solve this by recording what happened once and projecting it many times.
Caveats
- CQRS can be partial; non-CQRS areas can keep a unified model.
-
A small system can use transactional outbox events without full event-sourced aggregates.
-
Event sourcing is justified when history, replay, auditability, or projection repair matter.
Detailed Reference
For non-trivial implementation, review, or refactoring work, read references/details.md before giving final guidance. It contains the detailed rules, examples, smells, and migration notes that do not belong in the short invocation body.
Output
Explain the synchronization failure mode first, then recommend event sourcing, outbox-based events, or a simpler approach based on scale and risk.