Radu has been a software professional for a while now. He's worked on both small and large projects, small and large companies, and in this time he's learned a lot of stuff about code. He's passionate about extreme programming, flexible design, emergent architecture and refactoring, to the point where he won't stop talking about it.
Traditionally in application development we think of a database as the place to store the information about the current state of the app. Holding only the current state of the application doesn’t allow us to have a look at previous states of the application. This creates a few problems when dealing with certain constraints that you might have, like traceability.
Enter event sourcing, which is a representation of the events that lead to a state change, instead of just the current state.
Without telling too much we are going to look at the following:
- What is Event Sourcing and how we can think about it in comparison with a standard database (SQL/NoSQL)
- Some of the vocabulary that we need to know to be able to talk about Event Sourcing
- Some of the patterns associated with Event Sourcing
- Highlight some of the problems that are associated with an ad-hoc implementation of Event Sourcing and the solutions to them (think event versioning, distributed event logs, kinds of event handling, etc.)