Event sourcing dates back hundreds of years. This is how Functional Programmers think about event sourcing.
I love comments and questions. @britishdan / danielc@wix.com
2. Events
Client send Commands.
Commands ask the system to perform an
operation. Events are a recording of the action.
Commands are processed into Events.
3. Events
An event is something that has happened in the
past.
They are always in verbs in the past tense.
7. Think of your bank account.
Date Comment Change Current Balance
1/7/2014 Deposit from 756 + 1,000.00 1,000.00
5/7/2014 Check 1 - 400.00 600.00
6/7/2014 Purchase coffee - 5.00 595.00
7/7/2014 Deposit from 756 + 1,000.00 1,595.00
8. The last known value can be trusted because
at any given point we can run transactions from
the “beginning of time” for that account.
That is a verifiable audit log and versioning
system.
9. There are no deletes.
Events are never removed.
Deletes are modeled as a new event.
Append only models are easier to scale.
10. Event Sourced on the write side.
Simple, convert command to event and save.
Denormalized on the read side.
No joins. Flexible. Fast.
Snapshots/Views
11. A built-in audit log is priceless for debugging.
Play the events and watch the code in a
debugger.
You’re seeing the system as it was at the time
error occurred.
12. Different requirements on the query side.
You can be fully consistent.
You can be eventually consistent.
Each view is built with its consistency in mind.
13.
14. Simple for Functional Programmers.
Playing events on a domain object is a left fold.
events.foldLeft(this)(
(view, event) => view.applyEvent(event)
)