Event sourcing from wtf to why to wow
•Download as PPTX, PDF•
2 likes•387 views
This document discusses event sourcing, an approach to data management where changes to application state are stored as a sequence of events. It covers the definition of event sourcing, how to model data using events, and how event sourcing can be used with CQRS and microservices architectures. The presenter provides an overview of key concepts like command and query separation, event streams, and using an event store to share data across bounded contexts.
More Related Content
More from Duncan Jones
More from Duncan Jones (14)
Recently uploaded
Recently uploaded (20)
Event sourcing from wtf to why to wow
- 1. EVENT SOURCING FROM WTF TO WHY TO WOW Duncan Jones 💬 @Merrion Now with added CQRS and microservices
- 3. NOTES
- 4. DEFINITION OF EVENT SOURCING
- 6. COMPARISON TO RDBMS Performanc e ? Scalability? Business Fit ? Tooling ? Ease of use ? Developer Experience ?
- 8. USE WITH DDD/MICROSERVICES Event Store Projection Identity Group Cache Bounded context (Domain) Command Query
Editor's Notes
- 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
- Next steps:- 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.