- All commands result in recording an event with its metadata
- Save “what happened” instead of “what is”
- Use the lossless list of historical events to derive “what is”, including generating DB tables for easier querying (e.g. whether a user has verified their email address)
- Should simplify testing (“given these events have occurred when this command is received…”)
- Should simplify domain modeling
- Drawback is potential delay between event being recorded and derived state being updated, potentially resulting in referencing out-of-date state
Original video by Tom Delalande:
Event sourcing is no silver bullet. But it is a match made in heaven for some domains. I also don’t see much mainstream coverage of event sourcing, CQRS and domain driven design.
Thank you so much for taking the time to watch.
Timestamps
0:00 Problem space
0:40 CRUD implementation
1:12 Issues
1:48 Event sourcing
3:02 CQRS
3:34 Aggregate
4:05 Advantages
4:40 Disadvantages
5:08 Exit