Introduction

Event-driven architecture is a fast-growing approach in the software industry, where the smallest unit of information, known as an event, takes the central stage. Understanding the purpose of the created event queue or topic is important, and defining an event type can be helpful in achieving that. Among the available sources, one can encounter various names for event types. However, the problem lies in the inconsistency and the fact that authors rarely mention the criteria used to create these types. The purpose of this article is to establish a common approach to event type naming convention.

Why, where and what?

When working with events, we usually want to address the following key questions:

• why did the event happen? What is the purpose of sending or consuming that event?
• where did the event occur? Did it happen within the domain relevant to my context?
• what information doest the event provide? Does it offer the complete context, or will additional database access be required to obtain the desired information?

To answer these questions effectively, I propose a classification of event types based on the following criteria:

1. Purpose (why)
   1. Information event: This event informs about something relevant that happened within given system. (e.g. a payment was booked). System informing about it does not expect any specific action to happen. Typically, the producer of the event maintains it.
   2. Command event: Unlike an information event, a command event is used to initiate a specific action within the system, like creating a new user. In this case, the maintainer of the event usually will be it's consumer.
2. Context (where)
   1. Domain event: It reflects a significant change that happened within the domain context. Those events are also often considered private, as they are used only within that domain.
   2. Integration event: This type of event is used when more than one domain should be informed about the changes. The event would be produced within the context of one domain and consumed by the applications outside of that domain.
3. Payload (what)
   1. State transfer event: This event contains complete information about the state of entity. It does not require the uses of the event to fetch any additional information, so it is easy to work with. However, it may not be optimal if the entity's size is too large.
   2. Delta event: A delta event provides only the changes that have occurred since the last known state. It is efficient when the consumer only needs to know what has changed, rather than processing a full state.
   3. Notification event: This type signals that an event has taken place, but it typically lacks detailed information. It serves as an alert to prompt consumers to take further action if necessary.

It is important to note that an event can use many classifications and in fact it should. This is why I find it important to answer those three questions: why, where and what, before designing an event.

Payment processed example

Every event can be categorised differently based on the chosen classification criteria. Let’s consider a "payment processed" event as an example:

• Purpose: Since it informs about a completed payment, it can be classified as an information event.
• Context: This event is relevant within the accounting domain, making it a domain event.
• Payload: Depending on the architecture, the payload may vary. For this example, if the event provides all necessary details about the payment, it would be categorised as a state transfer event.

Final thoughts

Professionals familiar with Event-Driven Architecture will likely recognise the proposed event types, as this classification does not seek to introduce entirely new concepts. Instead, it aims to provide structure to ideas that are often applied inconsistently. I believe that having in mind the proposed classification, emphasises the intentionality of the design.

Though it might seem like the categorisation introduces additional complexity, I think it actually allows better architectural decisions. By explicitly addressing the why, where and what of events, this approach reduces ambiguity and fosters clearer communication among stakeholders.

I believe that the proposed standardised approach to event classification could provide significant benefits to the software industry and the event-driven architecture community.