I am currently learning about Event Sourcing via the book Microsoft .NET - Architecting Applications for the Enterprise. Event sourcing is, in my own words, an architectural pattern of storing "events" instead of "current entities". Current entities can be created by looping over the events belonging to it.
The problem of performance of creation of current entities can be mitigated by creating an extra storage where periodically the current entities are "snapshotted" (created from the previous snapshot and the events that happened after it).
In the book the architecture belonging to Event Source is setup as follows:
Here all events (related to a Waterpolo match) are stored in a NoSQL RavenDB store. We also see a bus to keep track of events and a saga which belong to groups of events.
I have a few questions about Event Sourcing (I decided to ask them all at once since all questions relate to the description in the book):
- I am wondering in what way these events would be stored. I can imagine that the data in events can change over time (extra properties, new event names) and that events need to be easily related to each other and itself. How does the actual structure of the database and data access code look to facilitate change and data retrieval?
- What is a saga? Why is it called a saga? Are they persisted and if so, how?
- How does a bus work? What are the advantages over just writing events directly to an event store?
- In the above architecture where commands and queries are separated (CQRS) and the commands are implemented using Event Sourcing while queries read from the snapshot, what happens when data needs to be displayed during the initiation of a command? (E.g., showing bank account data while a user wants to make a deposit, based on this data.) How, in practice, do we make sure the data displayed is up to date?