DDDEurope 2018 - Event Sourcing After Launch

DDDEurope 2018 - Event Sourcing After Launch

Event sourcing can be a solution for certain problems in your application, but it also comes with its own set of challenges. One of those is the evolution of your event schema. How should you handle changes to events?

We found many approaches while doing our research (we’ve published earlier results in our paper “The Dark Side of Event Sourcing”) and we gained a lot of experienced from building a full-size ERP application using CQRS and event sourcing. In this talk we will show what kind of approaches we’ve found and what we use to deal with our specific challenges. We will also share early research results from our interviews with over 20 different companies using event sourcing.

Every request for advice can be answered with ‘it depends’, and this talk will not solve that. But we will tell you what your options are, what we think works, and what many others have done.

03dc1d993fa7d5de422c1f35d53f80e6?s=128

Michiel Overeem

February 01, 2018
Tweet

Transcript

  1. 1.

    Event Sourcing after launch how to evolve your event store

    along with your application Michiel Overeem, AFAS, @michielovereem
  2. 7.

    20 years of ERP 10.000 customers 90% cloud Person Entity

    Customer Role Order Agreement party Spending limit Address Organisation Entity Delivery BusinessAc tivity party Invoice BusinessAc tivity party Address Address Spending limit Spending limit Own Organisation Workarea workarea Spending limit Put all our knowledge and experience in a model
  3. 8.

    Customized Web Scalable CQRS Event sourcing Person Entity Customer Role

    Order Agreement party Spending limit Address Organisation Entity Delivery BusinessAc tivity party Invoice BusinessAc tivity party Address Address Spending limit Spending limit Own Organisation Workarea workarea Spending limit
  4. 10.
  5. 14.
  6. 15.

    Which streams are in the store? Which event types are

    in which stream? Which attributes does an event have?
  7. 16.

    Applications that do not evolve in response to changing requirements

    or changing technology become less useful -Lehman, 1974
  8. 17.
  9. 19.
  10. 20.
  11. 24.

    “You align the events with real world events. You are

    dealing with changes that have a native equivalence. Doing DDD leads to less fragile design.”
  12. 36.

    “So one of the things you should never ever do

    is change existing events. An event written persisted to datastore is not like a hand wavy thing. It is a fact.”
  13. 42.
  14. 44.

    Variations 1. Create a new store from the old one.

    2. Create a new stream inside of the store, based on old streams. 3. Create new events in an existing stream.
  15. 54.

    Prevention Techniques Pruning Privacy Read models 24 interviews on event

    sourcing and upgrades Event sourced systems after launch are not scary
  16. 56.

    So, what is our solution? 1. Copy-transform of the whole

    store 1. 100.000 events in 4.5 minute (around 360 per sec) 2. Rebuilt query side 1. All projectors run in parallel 3. We deploy in blue-green
  17. 57.

    What do we (think we) want? 1. Renames are solved

    on the model level 2. Weak schema: handle new attributes with ease 3. Upcasters: solve complex cases without long delays 4. Copy-transform: 1. Remove upcasters 2. Only those streams that need it 5. Only rebuilt projections when necessary
  18. 58.

    Copyright Nasa Goddard Michiel Overeem @michielovereem Event Sourced Systems after

    launch: 1. Prevention 2. Techniques for upgrading 3. Prune your store 4. Think about privacy 5. Rebuilt your read models