In domain-driven design (DDD), domain events are events that occur in the domain and are relevant to the business. They represent something that has happened in the past or is going to happen in the future, and they are used to communicate changes and updates within the domain.

For example, in an e-commerce domain, a domain event might be a “product-added” event that is triggered when a new product is added to the inventory, or an “order-shipped” event that is triggered when an order is shipped to a customer.

Domain events are used to model the behavior of the domain and to communicate changes between different parts of the system. They are also used to decouple the different parts of the system, by allowing them to communicate through events rather than directly through function calls.

There are different ways to implement domain events in software, one of the most common ways is to use the publish-subscribe pattern, where the event publisher is responsible for creating and publishing the event, and the event subscribers are responsible for receiving and reacting to the event.

In DDD, domain events are used to model the behavior of the domain and to communicate changes between different parts of the system. It allows for different parts of the system to evolve independently and react to the changes in the domain. They are also used to decouple the different parts of the system, by allowing them to communicate through events rather than directly through function calls.

It’s important to note that domain events should be immutable, meaning that once they are created, they can’t be modified, this is important to maintain the integrity of the information and to avoid inconsistencies.

Design guidelines

Good domain events should exhibit several key characteristics that make them useful and effective for communicating state changes or significant occurrences within the domain. Here are some guidelines to keep in mind when designing domain events:

1. Express meaningful and significant changes: A good domain event should represent a significant change within the domain that is worth notifying interested parties about. It should not be trivial or insignificant.
2. Encapsulate context and details: A domain event should contain just enough context and details about the occurrence that it represents. This helps interested parties understand the event and take appropriate action.
3. Use clear and concise language: Domain events should use clear and concise language that is easy to understand by all interested parties. Avoid jargon or technical language that may be unfamiliar to some stakeholders.
4. Avoid creating too many events: While it is important to create specific events, creating too many events can lead to confusion and increased complexity. Instead, try to group related changes together to create fewer, more meaningful events.
5. Follow naming conventions: It is important to follow naming conventions to ensure consistency and clarity in event names. For example, use past tense verbs to describe what happened (e.g., OrderPlaced, UserRegistered) and use nouns to describe the subject of the event (e.g., ShoppingCart, User).
6. Document the events: It is important to document the events and their meanings to ensure that everyone involved understands their purpose and use.
7. Keep the events simple and focused: A domain event should be simple and focused on a single occurrence or state change. Avoid overcomplicating the event with unnecessary information or details.

Discovering domain events

Discovering domain events can be a challenging task, but there are several techniques that can help you identify and understand the significant occurrences and state changes within your domain. Here are some techniques that can be useful:

1. Domain Expert Interviews: Domain expert interviews involve interviewing people who are experts in the domain you are working in. These interviews can help you identify the key concepts, entities, and events that are important within the domain.
2. Eventstorming: Eventstorming is a collaborative workshop-style approach that involves a diverse group of stakeholders to identify domain events. During this process, team members map out the flow of events in a domain by writing events on sticky notes and organizing them into a timeline.
3. User Journeys: User journeys are a great way to understand the significant occurrences that take place in your system. By mapping out the steps users take when interacting with your system, you can identify the events that occur and when they occur.
4. System Logs: System logs can provide insights into the significant occurrences and state changes that are happening within your system. Analyzing system logs can help you identify potential domain events that may be useful to track.
5. Domain Analysis: Domain analysis involves studying the domain to identify the key concepts, entities, and relationships. This analysis can help you understand the significant occurrences and state changes that are important within the domain.
6. Use Case Analysis: Use case analysis involves analyzing the use cases of your system to identify the significant occurrences and state changes that are important within the system.

Thin vs. fat events

When it comes to designing domain events, there are two approaches – thin and fat events:

A thin domain event contains only the minimal amount of data required to communicate what has happened within the domain. These events are usually simple, with just a few pieces of data, and often only contain identifiers for the entities involved in the event. For example, consider an Order Placed event in an e-commerce system. This event might include just the Order ID and the Customer ID.

A fat domain event, on the other hand, contains all the information needed to fully describe the state change that occurred within the domain. These events are usually more complex, with multiple pieces of data and even nested entities. For example, an Order Placed event in an e-commerce system might include the Order ID, the Customer ID, the Order Date, the Shipping Address, the Items Ordered, and the Payment Information.

Both thin and fat events have their benefits and drawbacks. Thin events are simpler and easier to understand, but they require additional queries to retrieve additional information about the event. Fat events contain all the information needed to fully describe the state change, but they can be more complex and may be more difficult to maintain over time.

When designing domain events, it’s important to strike a balance between thin and fat events based on the requirements of your domain. In general, it’s best to start with thin events and only add additional data as needed. Over time, you may find that some events need to be fattened up to provide more context and improve performance. However, it’s essential to avoid overloading events with too much information, which can lead to unnecessary complexity and difficulty maintaining the system. On a related note, Martin Fowler’s article titled “What do you mean by event-driven” is worth taking a look at.

Examples

An example of a domain event is an OrderPlaced event in an e-commerce system. This event could contain information about the customer who placed the order, the items ordered, the total cost, and any other relevant details. Interested parties in this event could include the inventory system, the shipping system, and the customer notification system.

Another example of a domain event could be a UserRegistered event in a social media platform. This event could contain information about the new user, such as their username, email address, and any other relevant details. Interested parties in this event could include the authentication system, the recommendation system, and the user profile system.

A not so good example of a domain event could be a ShoppingCartUpdated event in an e-commerce system. This event doesn’t provide enough information about the occurrence, and it’s too generic. A better approach would be to create more specific domain events, such as ItemAddedToCart or ItemRemovedFromCart, which provide more context and detail about the occurrence.

See also

• basics
• faq