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

[@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.

[@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".

[@reachtrevor]

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

[@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.

[@JuanLuisCasanova-d4l]

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.

[@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

[@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.