Mistakes made adopting event sourcing (and how we recovered) - Nat Pryce - DDD Europe 2020

Domain-Driven Design Europe 2020
dddeurope.com - / ddd_eu
Organised by Aardling (aardling.eu/)
Join the next edition of EventSourcing Live
eventsourcing.... - / eventsrclive
Over the last year or so we have been building a new system that has an event-sourced architecture. Event-sourcing is a good fit for our needs because the organisation wants to preserve an accurate history of information managed by the system and analyse it for (among other things) fraud detection. When we started, however, none of us had built a system with an event-sourced architecture before. Despite reading plenty of advice on what to do and what to avoid, and experience reports from other projects, we made some significant mistakes in our design. This talk describes where we went wrong, in the hope that others can learn from our failures.
But it’s not all bad news. We were able to recover from our mistakes with an ease that surprised us. I’ll also describe the factors that allowed us to easily change our architecture, in the hope that others can learn from our successes too.
Nat has been programming for coughty-cough years, and programming in Kotlin since it was in beta. He introduced Kotlin into his current client and his team used it to deliver business-critical, customer-facing web applications. Now many teams in the company are happy users of Kotlin, and it powers many of their core services.

[@0w784g]

There's no problem so simple that some architect can't make complicated.

[@Ken-S]

I just found Hexagonal has some problem. Now we replace it with a brand new "Heptagon Architecture".

[@benjaminscherrey2479]

This was really one of the best "post-project experience reports" I've seen. We're doing similar architecture but with entirely different tech stack (Erlang mostly) but the issues described here are absolutely applicable. Would have liked to have heard more about the team structure and time periods of the project as well as non-functional issues such as performance, capacity, uptime, monitoring, etc. Of course those could likely be their own talks or their own paper I expect. Would love to hear more follow ups along those lines.

[@trevorpierce2007]

I am finding it quite annoying that every time I try to research Event Sourcing there's a oppressive amount of jargon that ends up not explaining anything, and some of that jargon are subjects that nearly encompass entire disciplines.

[@andy_lamax]

Funny things, I am in the middle of creating an in house framework and all the mistakes these guy did, We did as well (probably even more) lol, I learnt a lot today. Thanks for this video

[@MerrionGT6]

A key take away with event sourcing (and event driven architectures) seems to be that you need to avoid using the word "Event"..because it is too ambiguous and overloaded a term.

[@brentsteyn6671]

@Camie Touma Really man! No one f*king cares. I see this comment everywhere.

[@ktxed]

@@brentsteyn6671 please don't entertain the spambots haha

[@benjaminscherrey2479]

The confusion of Event Based vs Event Sourced is definitely a confusion that is hard to avoid. Definitely a thing that you need to be quite explicit about.

[@user-xw1jc1wy5t]

Some event storming techniques define the concept of "policy" as some business rule that needs to be executed as a result of an event. When that policy is triggered from an event outside its own bounded context that's a clue you're managing an event driven process.

[@mackie1001]

It seems like your goals were quite different to mine. I arrived at ES as a solution because data integrity (i.e. atomicity) was key and we wanted to publish events (so things can react to them - that's NOT a bad thing provided this doesn't leave the bounds of a given service) and audit all changes, all in a single transaction with no 2PC/distributed transactions available. Further to this we are using a partitioned DB (Cosmos) which severely restricts the scope of a transaction.