From WTF to WHY to WOW describes my own journey with event sourcing and how this forms part of a CQRS system which, in turn can form part of a DDD or Microservices architecture
The agenda is that I will do a quick “props based, no computer” show and tell to describe what event sourcing is, then discuss how it compares to a traditional database (RDBMS) then finish with some advice on how to get up to speed and start using event sourcing yourselves.
There won’t be any specific programming language used
This discussion is aimed at the beginner (level 101) although I hope it has some relevance even to those that have used event sourcing in the past
So first I am going to show how a database stores data (using the whiteboard) and then will show how the same data would be stored in an event sourcing data model (also referred to as event streaming). The business domain I’ll use is a very, very simplified bank account system.
Modelling an event source based system is not a massively different thing to modelling a database system.
You define the events that can occur to any given aggregate and all the properties that can be known about that event
Then you can define the projections that run over that aggregate to give you point-in-time data
You can extend this with commands and queries, and identity groups and classifiers.
There is no relationship part though – aggregates are considered logically separate.
So – how does event sourcing compare to a traditional database approach? We’ll look at the following categories but if anything else occurs while we are doing so shout it out so we can add it in to the mix. Performance Scalability Tooling Developer experience Ease of use Business fit
Commands can append events to the end of event streams
Queries can run projections
Projection results can be cached
The internals of an event sourced system should not be shared between domains
Only the defined Command and Query interfaces can be used outside of the domain
The best advice I can give you in terms of learning event sourcing (and this also applies to CQRS) is to experiment with it – either in a personal project or in a new build work project that allows for some flexibility.
If you want an out-of-the-box experience there is a project called “Event Store” at the URL geteventstore.com that you should give a go.
There are videos on YouTube – especially the “Goto 2014;” talk by Greg Young, a number of blogs by people like Daniel Whittaker and Dino Esposito and a good few folks on twitter discussing this (including myself) and the book “Event Centric: Finding Simplicity in Complex Systems” (also by Greg Young)
If you are a .NET developer there are two linked projects I am working on (hosted on CodeProject) – a CQRS / Event Sourcing framework that runs on top of Azure storage and a graphical designer for creating the event source based business model. Neither is production ready quite yet but getting there.
Now that we have a grasp on the idea of event storming we can add a bit of funky madness by adding the idea of treating the life cycle of each command and query as an independent event stream in its own right.
This event stream can be in the form of a queue which, in turn, means multiple independent agents (threads or microservices) can work on the same command or query asynchronously and that the processing of that command or query can go up or down as the command/query is in flight.
Theoretically this means that performance can scale linearly with addition of hardware.
Event sourcing from wtf to why to wow
FROM WTF TO WHY TO WOW