Comparison
CQRSvsEvent sourcing
CQRS
you stop trying to serve reads and writes from the same model and build a separate read model shaped for the queries.
Splitting the write model from one or more read models, so each is shaped for its own job rather than compromising. It is what lets a normalised write side coexist with a denormalised, query-shaped read side. The read model is now asynchronously updated, so the UI must tolerate a user not immediately seeing their own write.
Full entry →Event sourcing
you stop storing the current balance and instead store every deposit and withdrawal, deriving the balance by replaying them.
Persisting state as an ordered log of immutable events, with current state as a derived projection. You get a complete audit trail and the ability to rebuild any view by replaying history. What you give up is ad-hoc querying, cheap schema change, and the ability to ever delete anything easily — events are forever, including the ones with a bug in them.
Full entry →