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

Подписаться 30 тыс.

Просмотров 11 тыс.

0% 0

Domain-Driven Design Europe 2020
dddeurope.com - / ddd_eu
Organised by Aardling (aardling.eu/)
Join the next edition of EventSourcing Live
eventsourcing.live/ - / 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.

Наука

Опубликовано:

1 окт 2020

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 12

@0w784g 2 года назад

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

@andy_lamax 2 года назад

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

@trevorpierce2007 3 года назад

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.

@Ken-S 2 года назад

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.

@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 2 месяца назад

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 3 года назад

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 3 года назад

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

@ktxed 3 года назад

@@brentsteyn6671 please don't entertain the spambots haha

@mackie1001 2 года назад

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.

@md5ize 3 года назад

So in summary: the solution to not understanding event sourcing in soln 1 was to rename event to historical fact, use Postgres to index json fields, draw some hexagons, add more tests, improve your ci/cd pipeline, add more tests, use rest for async updates, test in production, add more selenium tests and tell the data analytics team that the shape of the data will change without notice. I look forward to soln 3 where you rename command to mandatory request, use Dropbox for storing emails, put an espresso machine on every desk, add pen-tests, clearly distinguish historic fact from alternative fact and use Wikipedia for planning poker.