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 EventStore 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:
- Evaluation of using NoSQL databases in an event sourcing system by Johan Rothsberg
- Object-relational impedance mismatch page on Wikipedia
- An introduction to event storming by a Steven Lowe, principal consultant developer at ThoughtWorks.