Events can be categorized into one of three types:2 event notification, event-carried state transfer, or domain events.

Event notification

An event notification is a message regarding a change in the business domain that other components will react to. Examples include PaycheckGenerated and Cam‐ paignPublished, among others.

The event notification should not be verbose: the goal is to notify the interested par‐ ties about the event, but the notification shouldn’t carry all the information needed for the subscribers to react to the event. For example:

{

"type": "paycheck-generated",

"event-id": "537ec7c2-d1a1-2005-8654-96aee1116b72", "delivery-id": "05011927-a328-4860-a106-737b2929db4e", "timestamp": 1615726445,

"payload": {

"employee-id": "456123",

"link": "/paychecks/456123/2021/01"

}

}

In the preceding code, the event notifies the external components of a paycheck that was generated. It doesn’t carry all the information related to the paycheck. Instead, the receiver can use the link to fetch more detailed information. This notification flow is depicted in Figure 15-2.

Figure 15-2. Event notification flow

2 Fowler, M. (n.d.). What do you mean by “Event-Driven”? Retrieved August 12, 2021, from Martin Fowler (blog).

In a sense, integration through event notification messages is similar to the Wireless Emergency Alert (WEA) system in the United States and EU-Alert in Europe (see Figure 15-3). The systems use cell towers to broadcast short messages, notifying citi‐ zens about public health concerns, safety threats, and other emergencies. The systems are limited to sending messages with a maximum length of 360 characters. This short message is enough to notify you about the emergency, but you have to proactively use other information sources to get more details.

Figure 15-3. Emergency alert system

Succinct event notifications can be preferable in multiple scenarios. Let’s take a closer look at two: security and concurrency.

Security. Enforcing the recipient to explicitly query for the detailed information pre‐ vents sharing sensitive information over the messaging infrastructure and requires additional authorization of the subscribers to access the data.

Concurrency. Due to the asynchronous nature of event-driven integration, the infor‐ mation can already be rendered stale when it reaches the subscribers. If the informa‐ tion’s nature is sensitive to race conditions, querying it explicitly allows getting the up-to-date state.

Furthermore, in the case of concurrent consumers, where only one subscriber should process an event, the querying process can be integrated with pessimistic locking. This ensures the producer’s side that no other consumer will be able to process the message.

Event-carried state transfer

Event-carried state transfer (ECST) messages notify subscribers about changes in the producer’s internal state. Contrary to event notification messages, ECST messages include all the data reflecting the change in the state.

ECST messages can come in two forms. The first is a complete snapshot of the modi‐ fied entity’s state:

{

"type": "customer-updated",

"event-id": "6b7ce6c6-8587-4e4f-924a-cec028000ce6", "customer-id": "01b18d56-b79a-4873-ac99-3d9f767dbe61", "timestamp": 1615728520,

"payload": {

"first-name": "Carolyn",

"last-name": "Hayes",

"phone": "555-1022",

"status": "follow-up-set", "follow-up-date": "2021/05/08", "birthday": "1982/04/05", "version": 7

}

}

The ECST message in the preceding example includes a complete snapshot of a cus‐ tomer’s updated state. When operating large data structures, it may be reasonable to include in the ECST message only the fields that were actually modified:

{

"type": "customer-updated",

"event-id": "6b7ce6c6-8587-4e4f-924a-cec028000ce6", "customer-id": "01b18d56-b79a-4873-ac99-3d9f767dbe61", "timestamp": 1615728520,

"payload": {

"status": "follow-up-set", "follow-up-date": "2021/05/10", "version": 8

}

}

Whether ECST messages include complete snapshots or only the updated fields, a stream of such events allows consumers to hold a local cache of the entities’ states and work with it. Conceptually, using event-carried state transfer messages is an asyn‐ chronous data replication mechanism. This approach makes the system more fault tolerant, meaning that the consumers can continue functioning even if the producer is not available. It is also a way to improve the performance of components that have to process data from multiple sources. Instead of querying the data sources each time the data is needed, all the data can be cached locally, as shown in Figure 15-4.

Figure 15-4. Backend for frontend

Domain event

The third type of event message is the domain event that we described in Chapter 6. In a way, domain events are somewhere between event notification and ECST mes‐ sages: they both describe a significant event in the business domain, and they contain all the data describing the event. Despite the similarities, these types of messages are conceptually different.

Domain events versus event notification

Both domain events and event notifications describe changes in the producer’s busi‐ ness domain. That said, there are two conceptual differences.

First, domain events include all the information describing the event. The consumer does not need to take any further action to get the complete picture.

Second, the modeling intent is different. Event notifications are designed with the intent to alleviate integration with other components. Domain events, on the other hand, are intended to model and describe the business domain. Domain events can be useful even if no external consumer is interested in them. That’s especially true in event-sourced systems, where domain events are used to model all possible state tran‐ sitions. Having external consumers interested in all the available domain events would result in suboptimal design. We will discuss this in greater detail later in this chapter.

Domain events versus event-carried state transfer

The data contained in domain events is conceptually different from the schema of a typical ECST message.

An ECST message provides sufficient information to hold a local cache of the pro‐ ducer’s data. No single domain event is supposed to expose such a rich model. Even the data included in a specific domain event is not sufficient for caching the aggre‐ gate’s state, as other domain events that the consumer is not subscribed to may affect the same fields.

Furthermore, as in the case of notification events, the modeling intent is different for the two types of messages. The data included in domain events is not intended to describe the aggregate’s state. Instead, it describes a business event that happened dur‐ ing its lifecycle.

Event types: Example

Here is an example that demonstrates the differences between the three types of events. Consider the following three ways to represent the event of marriage:

eventNotification = {

"type": "marriage-recorded", "person-id": "01b9a761", "payload": {

"person-id": "126a7b61",

"details": "/01b9a761/marriage-data"

}

};

ecst = {

"type": "personal-details-changed", "person-id": "01b9a761",

"payload": {

"new-last-name": "Williams"

}

};

domainEvent = { "type": "married",

"person-id": "01b9a761", "payload": {

"person-id": "126a7b61",

"assumed-partner-last-name": true

}

};

marriage-recorded is an event notification message. It contains no information except the fact that the person with the specified ID got married. It contains minimal information about the event, and the consumers interested in more details will have to follow the link in the details field.

personal-details-changed is an event-carried state transfer message. It describes the changes in the person’s personal details, namely that their last name has been changed. The message doesn’t explain the reason why it has changed. Did the person get married or divorced?

Finally, married is a domain event. It is modeled as close as possible to the nature of the event in the business domain. It includes the person’s ID and a flag indicating whether the person assumed their partner’s name.