Comparison
Command patternvsEvent sourcing
Command pattern
the request became an object with an execute method, so you could put it in a queue, log it and undo it.
Turning an invocation into a first-class object carrying its receiver and arguments, so it can be stored, passed, queued, retried, logged or reversed. That reification is the point — a strategy and a command can be identical in shape, and the difference is that a strategy is how to do something and a command is a particular thing to do. It is the object-level relative of every persisted-request idea, from job queues to event sourcing.
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 →