Event Driven Architecture EXPLAINED in 15 Minutes

What is Event Driven Architecture and why is it so popular these days? Event Driven Architecture is the most loosely coupled, most scalable approach to building large, complex and high performance systems, it may be implemented via collections of microservices or not, and represents a fundamentally different, and often better, way to organise the behaviour of our systems. But it can seem strange and different at first, until you realise that most people who have ever written any UI code are already experienced at it.

In this episode Dave Farley, author of best selling books "Continuous Delivery" and "Modern Software Engineering" and also a long term innovator in the use of Event Driven Systems, describes how Event Driven Architecture is an evolution from Event Driven Programming. What the benefits of this style of design and programming are and offers tips on how to best design them.

-

⭐ PATREON:

-

👕 T-SHIRTS:

A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!

🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

-

BOOKS:

and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-

🔗 LINKS:

-

CHANNEL SPONSORS:

#softwareengineer #developer

[Ashton]

Excelent video. I've recently designed, implemented, and deployed to production systems based on EDA, Event Sourcing, and CQRS. It radically changed the way I design and program systems, with incredible results: more cohesion, better separation of concerns, cleaner code code that is focused on the problem domain, with true object orientation, using DDD, highly and easily testable. Excellent response times, excellent maintainability. New feature were so easy to implement and discuss. Now it's hard for me to listen to a problema and imagine a solution in a different way.
About how to design it, I'd highly suggest a "step further" than event storming: event modelling. It starts with the same brainstorm concept, but the way it proceeds is a bit different, and I felt it makes it much easier to identify what are the business domains, and their bounded contexts in term of the business flow of the timeline.
Also, I must add: in the mentioned projects, I used a lot of the way of thinking that this chanel presents. I must thank you, Dave, as you confirmed a lot of things I've discovered ony my own, and taught me a lot more, and that played a crucial role in the success of these projects.

[orlandovftw]

While event-driven programming is the natural approach to solving a number of problems, it's not as easy as this video makes it out to be once you begin to build non-trivial systems. Issues like race conditions, where you cannot depend in which event handlers fire; dealing with situations where you need to wait for multiple events to trigger before proceeding; blocking operations locking up your process, etc.

[matthewlaborde]

These types of videos are highly valuable across the roles of an SDLC. I share your videos with everyone in my org.

[TeunSegers]

This is the single best video explaining EDA and related concepts I have ever watched. Not a second wasted and presented clearly, neutrally and insightfully. Bravo!

[DodaGarcia]

Great video as usual, Dave!! I'm also glad that you touched upon the point of how intentional design often ends up requiring more code, because I see that criticism pop up a lot whenever design patterns are discussed and usually as an argument against applying them.

I find that silly because in my mind it's a one-to-one analogy to physical organization in the real world. When we organize objects around a physical space, they'll always take more space than they would as a single pile, and keeping them organized will always take more work than the alternative. And yet, in this analogous scenario most people intuitively see the advantage in things being organized because of the time you save looking for things when you need them.

[marcinx]

I'm from a data engineer background, currently assigned to event-driven project. This video dropped just in time for me!

[Bennevisie]

Event driven architecture has been around for ages though. It just took forever for people to pay attention to it.

[peelypeel]

I appreciated the format, breaking down the pattern. I've only ever experienced "micro services" done badly, but Event Driven Architecture is the underpinnings of ms and this just makes so much sense as the method for developing systems

[vanivari]

9:08 ...yeah... unless you want to add a step between order processing and all the other activities (e.g. fraud detection, validation...) because now you have to know each service using the event and change it. And obviously, you need compensation events in case of errors (if debit fails, you don't add it to history). Now add 15 more activities and have fun understanding, what was actually happening with a failed order (and fixing it) because even with distributed tracing, it gets really hard to understand the order of events and which events trigger what when. Implementing, documenting and changing a business critical complex process with a choreography approach looks clean in a demo, but is a nightmare in many situations. I'm not against it, but it is a really challenging approach for most enterprises with their processes.

[justinbehnke]

Hi Dave,

I recently came across some of Adam Dymitruk’s work on Event Modeling, and I’m intrigued by his claims, but turned off by his tone.

He argues that traditional development practices like TDD and Agile are outdated and that Event Modeling is the future. My understanding is that Event Modeling is somewhat like Event Storming but uses the Muriel board as the basis for essentially all communication.

He suggests that by modeling systems as events, we can break down work into uniform slices, simplify the development process, and even implement a pay-per-slice compensation model, which he claims results in very low churn despite significant pay differences. I interpret that as meaning that the employees view it as a "tough but fair" pay model.

Given your experience with the actor model approach at LMAX (that you talked about in earlier videos, not this one), I’m curious about your opinion on Adam’s perspective.

Specifically:

- Are you familiar with Event Modeling as described by Adam Dymitruk?
- What do you think about Adam's claim that Event Modeling renders TDD, Integration Testing, and Agile wasteful and redundant due to the easy-to-understand scope of each slice?

He seems to have so much in common with you regarding what he would likely consider canonical works in the world of software, and yet he is coming to these radically different conclusions. And he is talking with this kind of "wake up sheeple" tone.

He claims to have loads of experience, but I trust your perspective because you have actually earned my trust, and apart from that, I know that you are both open-minded and able to smell if something seems fishy, yet his purported evidence has raised my eyebrows.


I know it's not your job to be the arbiter of truth and who has it, it's just that it has been nagging my brain of how to interpret what this guy is saying for the last few years on and off. And I would rather not put you in a position to say something negative about someone else, but still I felt compelled to seek out your opinion, and today you are talking about Event Driven Architecture and I thought "that's it! I am going to ask"

Thank you!

[KuldipChakraborty]

Thank you for a new perspective on a possible point of evolution in system architecture. I had never seen events as possible extension points in a system.

[sirskaro]

I do like these design-centered videos. I also feel, like you said, it only scratches the surface. I feel like there's a tension there of breadth vs depth.

[freeborn]

Great video! In java, Spring makes this super easy. You can setup a bean that returns all types of Interface X, and then that becomes a dependency of the event triggerer, and it just triggers on all registered events. Then you can build a fair amount of your system in a modular monolith, and split it at any time when you've discovered the clear boundary between services. Or, if you're not in need of super scalability, delay that decision as long as you want.

[stuartnelson]

Good stuff, I appreciate the overview of the benefits of applying event driven architecture to more than GUI's.

[majormartintibor]

Excellent video, excellent format.
I am a big fan of EDA. One of the most underrated things in Software Development is the ease to reason about your code in a way that the business side also understands. EDA helps a ton with that, especially if combined with stuff like Event Storming as you mentioned, but I would mention Event Modeling as well.

[andrewjuhasz]

Great video. I was working on a project, where we tried to implement event driven arch on aws using Lambdas, Sqs, Dynamo, Event buses etc. It was hard for developers to write code not in the imperative way and it often ended up with another service direct lambda invokes, or millions of retries(which is a pain to handle when some parts of system are not idempotent). Another problem was working with logs of the system. It was the first experience and I liked it very much. Waiting for new videos on this topic!

[dedalusow]

After over 20 years of professional programming, event sourcing with CQRS is the closest to a silver bullet I've seen. Contrary to what I was expecting, it also scales down really well to really simple systems.

The biggest issue standing in the way of adoption right now in my opinion is that there aren't standard free software solutions to implement it based on common databases. That means you have to write a few slightly tricky parts yourself to get event handling to work. However, once I have implemented these parts in my stack, I can reuse this code again and again for new projects.


Of course as with anything there are cases where this architecture is not a good fit, like for example if eventual consistency can not be tolerated. But when there are no fundamental issues, I'd go for ES+CQRS ten times out of ten.

[Fjonan]

This couldn't come at a better time :)) pitched an event system to our app team and could not make clear what I meant. Will link them to this video that clearly makes a better job at explaining than I did.

[neilthomas]

The key to making your system 'growable' is to make sure the events are business events, real world logic. Anything you are asked to add at short notice later will naturally call on real world business events, rather than idiosyncratic programming tweaks you happened to use earlier.

[justinlynch]

Omg i love these types of videos. I find it's very difficult to find resources i trust on design topics