Event Driven Architecture EXPLAINED in 15 Minutes

event driven architecture has become popular in the past few years and there are very good reasons for that so what does event driven mean and why is it so popular particularly for bigger more complex and high performance [Music] systems hi I'm Dave fary of continuous delivery and welcome to my channel if you haven't been here before please do hit subscribe and if you enjoy the content here today hit like as well as ever this is a lot about design and ways of thinking more than specific technology choices but the technology kind of matters too in this episode I want to explore the basics of event-driven programming and event driven architecture and what it gives us why is this quite so popular as a model particularly for larger systems and I want to talk about some of the useful ideas and techniques involved in making it work whether on a small or very large scale i' also Al like to offer my advice on ways to approach identifying and structuring your design around events event-driven programming isn't a new idea and neither is event driven architecture but perhaps more importantly what is it most of the time when we write code each piece of code issues commands to other parts even if these commands are in the simple form of a function core that's mostly how things are structured event-based programming kind of inverts that instead of one piece of code commanding another to do something instead we tell other parts of the system that something interesting happened and those other parts then respond so we issue an event when something interesting happens in our code and other code may or may not be listening for that event at the point when you write the code issuing the event it doesn't know or care if there's something listening then it can act on the event but if not no Harm's done this simple inversion of the conversation quite dramatically reduces the coupling between the parts of our code how we implement this approach can be as simple as something like this where we code the listening and the publishing explicitly ourselves or it can be really quite complicated with sophisticated middleware to transport the events generated by Publishers and help subscribers to register interest in them there are lots of benefits to organizing our programming this way but it can seem a bit weird at first if you're not used to it the most important benefit is that this decouples the pieces of our code from one another so not only in this example does event publisher not need to know anything about event listener except how to send it events but it would be easy to code it so that it could have multiple event listeners and send them all events whenever something interesting happens leaving them to deal with what they decide to do with it this pattern is widely used and it's how all graphical user interfaces work based on an oo event-based system of programming when your code is informed that something interesting has happened like a window repaint or a button click your code then gets to decide how it should respond when this relatively generic event happens let me just pause there and say thank you to our sponsors we're extremely fortunate to be sponsored by equal expert transic and semaphore all of these companies offer products and services that are very well aligned with the topics that we discuss here every week so if you're looking for excellence in continuous delivery and in software engineering in general do click on the links in the description below and check them out most of us are familiar with this form of code these days because as I said some form of this is essentially the model that we use to write pretty much all GUI code that I've ever seen so if you've ever written any GUI code code you're already probably an event- driven programmer this is a powerful technique for not only decoupling code but also for compartmentalizing it into discrete pieces which are each clearly focused on doing one thing which is in general a very good thing so amongst other things this stup programming encourages a much better separation of concerns in our designs because code for rendering your display is now separate from code to handle a click explicitly separate because it's responding to a different event which is separate from code to validate input from a text box and so on of course this isn't only about UI code this is just as true of anything else and with a bit of thought you can use this approach to organize pretty much all of your code if you choose to the downside is as you can see from my examples that even in these simple cases there is a little bit extra code needed to register the listeners and to publish the events but as you can also see this doesn't need to be very complicated or very sophisticated at all if you'd like to help us and support our Channel and get your YouTube videos without interruption by Google ads and maybe sometimes ahead of their release on YouTube join our patreon supporters for as little as 2 a month as a patreon you also get exclusive discounts on my training courses and regular free how to guides to keep you on top of the latest in software development the link to our patreon page is in the description below The Next Step Beyond the basics of event-based programming is to start thinking about generalizing and externalizing the code that manages the events and their routing we can treat these events as discrete messages sent from one piece of code to another each message is self-contained and we can leave the rooting and management of the life cycle of the message to the supporting infrastructure now the messaging infrastructure can register the interest of a subscriber or listener to the messages published retry messages if the receiver wasn't ready for them monitor traffic volumes and so scale systems by starting up new copies of services to take extra load when needed as well as managing things like rooting delivery semantics like at most once exactly once or at least once and add services like clustering persistence resilience security and so on all of this outside the code that you have to write to do the job of your application of course you can still use facilities like these to build imperative command oriented designs but you really take advantage of this kind of infrastructure and embrace a more genuinely distributed approach to design when you also embrace the idea of events and build very Loosely coupled systems with them taking advantage of the natural resilience and scalability available in truly distributed systems but ducking their complexity to some extent by largely externalizing their accidental complexities from the code that you need to write I should warn you that not everyone agrees with my take on this but I believe that event driven architecture significantly reduces the complexity of otherwise very complex systems in complex Real World Systems you probably need a bit of both of these Styles imperative and event-driven to be honest but in general I would recommend that you try to see these packets of communication between the parts of your system by default as messages in the form of events to get the best out of them I say this because thinking of these things as events helps us to design better more Loosely coupled systems and to make more easily distributed distributed systems for example I could choose to place an order and when my order is placed the code that records it goes on to find the relevant account deduct the payment and update the account history to record that the order had been placed or we could implement this as a more event-based system this second version doesn't look very much different in my diagram the same stuff tends to happen but is orchestrate orchestrated in a very different way this though is very different order processing is a lot simpler ignoring what it needs to do internally at least externally it only needs to publish one message instead of two order placed if these messages are asynchronous as well and have some form of Assured Delivery order processing can fire and forget the order placed message allowing it to carry on doing other useful work as soon as it is sent the message using techniques like these our financial exchange at elmax could process and generate literally millions of messages per second the enormous value here in terms of design though is that if we model our systems this way as a series of events moments in time when something interesting happens and generate messages that say something interesting happened rather than do this thing then it's trivially simple to add in more behavior when we need it the the system is kind of primed to expect new Behavior almost I can add brand new service to my system and the only code that I need to add or change to do this is for that new service everything else remains untouched and the same my new service will fit in and do useful work based on the messages of the events that are already being sent this decouples programming and teams as well as software so our new dispatch service here may generate new messages of its own that nothing is interested in yet but sometime later we could decide to add something new that responds to the ordered dispatched message and so grows the capability of the system further this ability to grow the system in unforeseen ways is very powerful but even if we don't know yet that we may need an order dispatch message or that it might be helpful it would be very easy easy to add even if we do decide to change the code in the dispatch service when we found the need for that new message this design approach isolates change better than any other allowing systems to grow incrementally and in unplanned ways the secret here is to model the problem domain so combined with their ability to almost completely hide The Accidental complexity of our systems from their core logic event-based systems are in almost perfect fit with domain driven design design where we build our code as a kind of software simulation of the problem that we're solving so my best advice when defining your events is to try and track the problem domain closely be suspicious of technical or tactical events but instead look out for business meaningful problem level events a good way of Sanity checking these things is to try and make sentences from them from my example when an order is placed the account is debited the order is added to order history and is dispatched and a notification of the dispatch is sent this description comes directly from the design of the system and even the least technical person who understands the problem can now also understand how the system works as we progress down this track inevitably things can become more complicated but in my opinion always in a simpler way than the Alternatives I've said this before in the context of microservice design but I think that it's useful to think of the design of systems like these in three parts try this video next there's a link to it at the end of the one that you're watching now we need to work on three levels in our design identifying sensible components for our system defining the conversations between them and identifying the key Concepts that link the different conversations so that we can see the a coherent picture I think that event-based architecture and taking an event-based approach to the modeling of our systems helps a lot with all of these things the first two tend to fall out rather naturally from a process called event storming where we model the system with whiteboards and sticky notes along with the people who understand the problem domain very well our domain experts the idea of event storming is to establish a timeline for the system and then to imagine the events that happen in that problem domain along that timeline these events are things that trigger actions and we can use that as a way to explore and Link together often very complex processes there's a link to more details of how to do that in the description by creating this highlevel picture of a system it can often help us to begin to see clusters of related Behavior to identify bounding contexts and see the events that flow between them the last layer of my three elements of design for systems like these is to identify the Core Concepts the keys that allow us to track the flow of events through the system Co cently if we have orders or accounts that we need to keep track of let's come up with a way of assigning each one of them a unique identifier that we can use everywhere and maybe USE events to inform interested parties of new accounts or orders then we can rely on this to keep track of even very different changed flows of events and understand whole conversations rather than single interactions with one service at a time and we can see how those conversations are related to one another making tracing what's going on overall much easier there's obviously an awful lot more to event-driven architecture than only this common patterns that are extremely helpful like using our services as state machines to keep track of what is happening as they respond to sequences of events or cqrs command query responsibility separation where one part of the system Services commands and another queries of the results from those commands then there are problems that can challenge us like if our events the conversations in our system represent one model and our services a slightly different though clearly closely related model how do we keep them in Step how do we update a service and allow it to process old events or update events and retain old Services I've spoken a little about some of these things before when talking about reactive systems but these are probably topics for another day let me know in the comments if you like this more design and architecture style topic like like this do let us know in the conversation thank you very much for watching and if you enjoy our stuff please do consider supporting our work through joining our patreon community and to our existing patreon supporters thank you very much indeed it's your help that allows us to maintain the delivery of videos like this thank you [Music]

Channel: Continuous Delivery

Views: 15,816

Keywords: event driven architecture, event-driven archetecture pattern, event driven microservices, event driven archetecture examples, event-driven architecture microservices, what is event driven architecture, event driven programming, event driven architecture tutorial, event driven architecture explained, what is event driven programming, microservices, event driven software architecture, event driven model, software engineering, software development, dave farley, continuous delivery

Id: Fb_0UOD2X2I

Length: 14min 55sec (895 seconds)

Published: Wed Jul 10 2024