Member-only story
The Event-driven architecture style may seem simple to adopt, but on the field it could lead to conceptual issues. The main issue about events lies in its purpose. What is the intent of each emitted event? Is it a broadcast or targeting a specific consumer? Who would consume it? Is it a command or just a notification? Does the order of events delivery matter? Is duplication a problem? How about fault tolerance or delivery guarantee? Let’s try to get answers to those questions.
Related articles:
- Software Architecture — principles, rules and styles
- Event-Driven Architecture
- Service-Oriented Architecture (SOA)
- Microservices Architecture — a step further than just SOA
- Hexagonal architecture
Introduction
If there is a lack of governance from an architecture point of view, then there will be hidden problems, as teams won’t easily find the source of truth about events. Typically teams who produce should define and document what are events that are produce. Besides, events should reprints domain events, so they should be understood and known by anyone whos needs to consume the. The owner team (if not architect) should be there to aid and make sure to make events visible with purpose.
Event-Based vs Event-Driven
Before we go further, let’s clarify the difference between event-base and event-driven.
The event based architecture is meant to facilitate the communication between systems or components. However, it does not specify the nature of it, so it could be real-time or not, synchronous or asynchronous. In other words, events are used to communicate.
On the other hand, the event-driven architecture style is more specific, as it suggest to design the system with asynchronous events. That leads to an architecture style suggesting to use several patterns such as choreography and orchestration, and to use specific nature of events for communication, as to notify or to make a command toward other components. You may read this Event-Driven Architecture article for more details
