Event-Driven Architecture: I do not think it means what you think it means

preview_player
Показать описание
With the popularity of Microservices, Kafka, and Event Sourcing, the term "Event" has become pretty overloaded and has caused much confusion about what Event-Driven architecture is. This confusion has led to conflating different concepts leading to unneeded technical complexity. I'm going to shed some light on different aspects of Event-Driven architecture, such as Event Sourcing, Event-Carried State Transfer, and Events for Workflow.

🔗 EventStoreDB

💥 Join this channel to get access to a private Discord Server and any source code in my videos.

🔥 Join via Patreon

✔️ Join via YouTube

0:00 Intro
4:56 Event Sourcing
9:48 Data Distribution
16:43 Notifications
23:50 Tooling

Referenced Blog Posts

Don't Let the Internet Dupe You, Event Sourcing is Hard

Event Driven Architecture — 5 Pitfalls to Avoid

#softwarearchitecture #softwaredesign #eventdrivenarchitecture
Рекомендации по теме
Комментарии
Автор

Some of these concepts have been explained in Derek's previous videos, but I appreciate that he doesn't mind repeating himself. I've found it has helped me quite a bit hear things explained again, perhaps slightly differently, and reinforces my understanding.

KA-wfrg
Автор

Excellent presentation once again!!
2 points I would add are:

1) Event Sourcing is the in order persistence of application state change events as they occur to be replayed later in order to rebuild application state to current state
2) Domain events should be used within your domain for internal workflow processing and Integration events should be used to globally notify any non-domain services externally

Best point that I totally agree with: Event Sourcing is an implementation detail. Absolutely accurate and this should be clearly understood BEFORE trying to implement an Event Sourced system.

basilthomas
Автор

Great video and good explanation of the concepts of EDA.

In my opinion events that carry state are really tricky and should be avoided when possible. One of the reasons is that the order of processing those is almost always crucial, additionally those kind of events become really fat fast (as you mentioned). When you need some state from other service to do some business logic, use notification events to invalidate, fetch & update the local cache. When that service is down for some reason, fetch the data from the local cache and make some assumption about the "accepted" data staleness. Further optimalisation could be made by throttling the remote service calls, having ttl or using techniques like stale-while-revalidating.
For analytics purposes like datawarehouses etc use ELT or ETL techniques, you almost never need realtime analytics and if you do, it probably falls outside analytics...

ilijanl
Автор

Is there any good book explaining EDA in details? If yes, then which one?

NervousNab
Автор

I have never thought of Event-Driven as requiring Event Sourcing. I've worked on several Event Driven architectures, and none of them used Event Sourcing. Odd how terminology is different to different people.

Tony-dprl
Автор

I love how the focus is on the concepts rather than the nitty-gritty implementation

tristanstricker
Автор

The rainbow blog post has tortured me for years

mathewmcloughlin
Автор

Hello

I'm building loan application for my college project; I want to build form builder and workflow for that. I have orchestrator who manages current stage, next stage and so on.
I want to understand what orchestrator can do and when workflow should be initiated?
I have created multiple forms using form builder and those forms are assigned to different stages in workflow.

according to me orchestrator is just responsible for marking current stage status and next stage status.

Doest orchestrator will responsible for calling forms, and will it also responsible for hiding/showing form fields based on permissions?

hemantpanchal
Автор

At 3:04 you say, "The FOUR concepts I really want to talk about ..." Then you proceed to list THREE items, and on the next slide, FIVE items. Please clarify. (IF the clarification is later in the video, please understand that this kind of thing can stop a person from getting to the rest of the video.)

StewartCambridge-iusw
Автор

My current client wanted to build an event-based architecture for some of their internal line of business applications. So for some reason they chose to build it on Azure Service Bus, and for some reason the events are essentially Event Carried State Transfer without capturing any domain intent, it's basically just the U in CRUD.

Let me tell you... it's an absolute dumpster fire. I've never been less productive in my career as a consultant. We're always running into issues where we can't develop certain features because the architecture is actively preventing us, and if something goes wrong, it's almost impossible to answer what actually happened after the fact.

GackFinder
Автор

event sourcing is still bad as I donot understand what is fact? how fact is event sourcing but not state, domain event, or what is happening? on the other hand i also don't like the idea to use event sourcing to update state - that is only good for system state or low level state more for machine-level events but not for business-level events.

kopiking
Автор

Are you aware of an IT terminology dictionary? It triggers me that you keep using terms I don't know the meaning of so I have to pause and lookup then continue etc. If it doesn't exist why the heck not?

emonymph
Автор

Bro, this pronunciatioooon, this is so 😭😭😭

this-is-bioman
Автор

First of all, thank you for great video as usual and I must excuse for my poor english language skill.

I have been confused by your example of orchestration doing on client, what happens with already written data on service "A" if client can not execute command on service "B"? I understand idea of workflow engine, like Comunda, as a core of business-processes management in distributed system, but client itself, or some type of smart-gateway - is not seems a good idea for me. May be you can provide some more detailed mention about it?
I have build large distributed enterprise system with event sourcing and used ES events to distribute state, with sagas if i have need some consistency, of course i used BPMN engine to orchestrate some large-scale and configurable processes, but lots of contexts was coupled through ES events state distribution. For example: Employee has some attributes that have matter in salary calculation, we have context that manages Employee and attribution changes, and context of salary calc, attributes means slightly different for contexts, but are relevant in both. Tell me please what is wrong in this?

evgenvb
Автор

8:10 "Event Sourcing is that we will store *facts* which have occurred" then, dear Mr. Young, why the heck did you name it event sourcing instead of FACT sourcing?!

lucasterable
Автор

This is exactly what happened with TDD... later on with BDD... It is anoying as fuck this semantic diffusion thing.

ThugLifeModafocah
Автор

Event sourcing has been around for 5, 000 years. 🙂
Love the breakdown in this presentation.

th_CAV_Trooper
Автор

I'm starting developing an EDA architecture, I'm currently facing a concern about doing it asynchronously or synchronously because we have a backend for frontend service that is listening a queue (running on a single thread) to reflect any data change in "real-time", we don't have async code on our Python modules to consume, produce messages but if we would like to migrate it to async it would affect the data consistency because of the async processing nature, what do you recommend us to implement/investigate/review? sorry if you already talk about it in the video, probably I missed it but would be great some extra insights about this kind of issues. Thanks for this amazing channel!

ItsGonnaRaiN
Автор

Fantastic video and I enjoyed how you focused on the high-level concepts here. Bravo!!!!

conradtaylor
Автор

In which way is this choreography if one of the components (the client in the presented example) is the one that holds the business process logic (order of the calls)?
What I know is that choreography has no central point for business process logic, but as we plug in the events to react to each other we get that implicit process as part of events reacting to events.

kobac