“In my previous blog, I delved deeper into the meaning of Event-Driven Architecture. This blog marks the second part of a series dedicated to exploring Event-Driven Architecture. It is important to note that the viewpoints expressed in these blogs are my own and are subject to ongoing discussions within our community”. Our Integration Architect Joost sets the scene!
Before we delve into the different event types, I want to emphasize that these blogs will not focus on the structure or content of an event itself. This issue stands alone, distinct from our present topic. However, classifying your events can significantly streamline these discussions.
My main argument is the importance of classifying your events by their role in your architecture. With this premise, we can distinguish two main types of events.
Business Events
These events aim to drive forward a specific business process or workflow. They serve as signals that a significant event has occurred within a process, thereby cueing the next component or actor to perform its task. This is, in my view, an excellent illustration of implementing a business process using choreography.
Side Note: Event Sourcing
Event Sourcing can also be classified as a type of event. However, I’ve excluded it from this discussion because it’s more associated with the internal architecture of a specific component within a given solution. It’s a method for capturing and managing state within a particular component. In this blog, my focus is more on the overarching architecture of a business solution, where the relevance of event sourcing is not as pronounced.
Data Events
The purpose of these events is to propagate state information to other components within a specific business solution. This design pattern has gained increased attention with the rise of microservices, enhancing the robustness of such architectures.
By transferring state/data from a master microservice to other microservices, the system can continue processing even if the master microservice becomes temporarily unavailable. This approach also improves the performance of certain operations, as the data becomes locally accessible, effectively functioning as a local cache.
When designing an event-driven system, it’s crucial to consider this distinction, as it influences the requirements and design of these events. I would argue that keeping them separate is always a good idea. This approach can make your architecture more adaptable to changes in future requirements (see the following example below).
Again, my focus isn’t on the content of the events, like notification events or state-carrying events, as outlined by M. Fowler (https://martinfowler.com/articles/201701-event-driven.html). [ZK1] My argument revolves around the idea that the discussion should be guided by the purpose of the event—whether it’s business-oriented or data-driven—and there are valid reasons for both types to carry a certain degree of state information.
Simple Example
This simple example is intended to illustrate my point.
Situation:
Consider a straightforward ordering process involving three components within a business solution:
- Ordering Component: Captures the customer’s order.
- Payment Component: Facilitates the payment for outstanding orders.
- Warehouse Component: Manages the shipping of the order.
Here’s how the process unfolds: when an order is placed, the system triggers a payment request. Once the payment is successfully processed, the order is then shipped by the warehouse.
To maintain system robustness, we aim to prevent the entire process from breaking down if any of its components become unavailable.
