Event sourcing - from wtf to why to wow
•Download as PPTX, PDF•
0 likes•522 views
An introduction to "Event Sourcing" and discussion on where it fits in CQRS, Microservices and DDD
Recommended
Recommended
More Related Content
Similar to Event sourcing - from wtf to why to wow
Similar to Event sourcing - from wtf to why to wow (20)
More from Duncan Jones
More from Duncan Jones (20)
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 DDD
- 3. Notes
- 4. Definition of event sourcing
- 6. Comparison to RDBMS Performance ? Scalability? Scale UP Scale ACROSS ! Eventual Consistency
- 7. Comparison to RDBMS Business Fit ? Ledger / transaction based Document based, Less structured WRITE heavy READ heavy
- 8. Comparison to RDBMS Tooling ? Ease of use ?Developer Experience ?
- 9. Use with CQRS Query Command Projection Event Streams Cache Definition Implementation Identity Group Definition Implementation Identity Group Collate
- 10. Use with DDD and/or microservices Event Store Projection Identity Group Cache Bounded context (Domain) Command Query
- 12. Next steps Experiment https://geteventstore.com/ CQRS Designer (.NET) Azure Event Grid
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
- 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
- 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
- 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.
- 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.