Event-driven architecture primer - Azure Tutorial

- [Instructor] Let's now describe what an event-driven architecture means for our microservices solution, and how it would look like. Event-driven architecture is all about enabling asynchronous collaboration between microservices. If contrast with the synchronous communication pattern that we can easily implement between two or more microservices the main problem with this pattern is that when you directly communicate to a service from another service it creates a temporal coupling between those two, and any kind of coupling is precisely what we would need to avoid when building robust and scalable microservices applications. We should always strive for autonomous services that could be deployed in isolation without impacting other services. The truth of the matter is that if a microservice relies on another to fulfill a request then it isn't truly autonomous. As you could imagine, the problem worsens when more than two microservices are involved in the same chain of requests. For example, what happens in this scenario if Service C fails? It'll create a domino effect that goes back to the original caller. That's precisely why most of the time it's a better idea to have asynchronous communication between services based on events. In this architecture we always have three main elements, event producers that create events. These events originate from the domain logic of the application. Oftentimes the event producers are not aware of which components or services are interested in receiving those events. The second element is indeed the event consumers, and the third element is the event broker, platform, or application that we use in our system. There are so many different products in this category and all of them have the same goal, to enable loosely coupled communication between services. To accomplish this the event consumers subscribe to a particular event or set of events that they are interested in. When the event publishers actually publish one of those events the consumers receive the event and its related data. In this fashion we could have dozens, hundreds, or even thousands of microservices receiving events in a loosely coupled way. This is one excellent way to achieve true autonomy. As I've already mentioned, there's an abundance of platforms and products that perform the same goal of asynchronous sending and receiving of events. However, in this training course we'll use Azure Service Bus. Technically we provision an Azure Service Bus namespace, and inside the namespace we create topics. We could also create queues, but that's out of the scope in this course. After creating the topic we create a subscription for that particular topic. Then our microservice application communicates to the subscription to publish or consume the events. Now it's the perfect moment for you to provision your Azure Service Bus namespace that you're going to use in this course. Please be sure to create the following topics and related subscriptions. There are two other concepts that I'd like to discuss, domain events and integration events. Both of them are essential topics in domain-driven design, and we use them a lot in the accompanying code of this course. Both the main and integration events represent facts in the domain logic. In other words, something that happened in the past, something unchangeable. The difference is in the way that we handle those events. For instance, domain events are handled in process and trigger side effects in the same domain whereas integration events are handled out of process and trigger side effects in a different domain. Additionally, domain events are created in the core domain layer whereas integration events are created in the application layer. Of course, there could be many different ways to implement them. However, this is the way they're implemented in the code. Okay, you've already seen a bit of event-driven architecture, now it's time to roll up our sleeves.