Background¶
Although the event sourcing patterns are each quite simple, and they can be reproduced in code for each project, they do suggest cohesive mechanisms, for example applying and publishing the events generated within domain entities, storing and retrieving selections of the events in a highly scalable manner, replaying the stored events for a particular entity to obtain the current state, and projecting views of the event stream that are persisted in other models.
Therefore, quoting from Eric Evans’ book about domain-driven design:
“Partition a conceptually COHESIVE MECHANISM into a separate lightweight framework. Particularly watch for formalisms for well-documented categories of algorithms. Expose the capabilities of the framework with an INTENTION-REVEALING INTERFACE. Now the other elements of the domain can focus on expressing the problem (‘what’), delegating the intricacies of the solution (‘how’) to the framework.”
Inspiration:
- Martin Fowler’s article on event sourcing
- Greg Young’s discussions about event sourcing, and Event Store system
- Robert Smallshire’s brilliant example on Bitbucket
- Various professional projects that called for this approach, for which I didn’t want to rewrite the same things each time
See also:
- Object-relational impedance mismatch page on Wikipedia
- From CRUD to Event Sourcing (Why CRUD is the wrong approach for microservices) by James Roper
- Event Sourcing and Stream Processing at Scale by Martin Kleppmann
- An introduction to event storming by a Steven Lowe, principal consultant developer at ThoughtWorks