Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
What to Upload to SlideShare
What to Upload to SlideShare
Loading in …3
×
1 of 12

Event sourcing - from wtf to why to wow

0

Share

Download to read offline

An introduction to "Event Sourcing" and discussion on where it fits in CQRS, Microservices and DDD

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Event sourcing - from wtf to why to wow

  1. 1. Event Sourcing From WTF to WHY to WOW? Duncan Jones 💬 @Merrion Now with added CQRS and DDD
  2. 2. Agenda What Why How
  3. 3. Notes
  4. 4. Definition of event sourcing
  5. 5. Modelling using events
  6. 6. Comparison to RDBMS Performance ? Scalability? Scale UP Scale ACROSS ! Eventual Consistency
  7. 7. Comparison to RDBMS Business Fit ? Ledger / transaction based Document based, Less structured WRITE heavy READ heavy
  8. 8. Comparison to RDBMS Tooling ? Ease of use ?Developer Experience ?
  9. 9. Use with CQRS Query Command Projection Event Streams Cache Definition Implementation Identity Group Definition Implementation Identity Group Collate
  10. 10. Use with DDD and/or microservices Event Store Projection Identity Group Cache Bounded context (Domain) Command Query
  11. 11. Funky follow ups Query Command Cache Passive “Observer” Active Query
  12. 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.
  • ×