How do you balance the granularity and frequency of domain events and integration events?

1 Why granularity and frequency matter

The granularity and frequency of events affect how much information is transmitted, stored, and processed by the system. Too coarse-grained events can lead to data loss, duplication, or inconsistency, as they may not capture the relevant details or changes of the domain. Too fine-grained events can lead to data overload, latency, or complexity, as they may generate too many messages or require too much logic to handle them. The optimal granularity and frequency depend on the context and the requirements of the system, such as the availability, scalability, and security of the components involved.

3 How to design integration events

Integration events should respect the autonomy and the contracts of the bounded contexts. They should be designed to minimize the coupling and the dependencies between the contexts, and to avoid leaking domain knowledge or logic across the boundaries. They should be based on the published language and the anti-corruption layer of the contexts, and use a common data format and protocol. They should also be reliable, resilient, and secure, meaning that they can handle failures, retries, and attacks without compromising the system integrity.

4 How to balance domain events and integration events

There is no one-size-fits-all solution for balancing domain events and integration events, but there are some guidelines and trade-offs to consider. One guideline is to use domain events within a bounded context, and integration events across bounded contexts or external systems. This can help to preserve the cohesion and the encapsulation of the domain logic, and to reduce the complexity and the overhead of the communication. Another guideline is to use domain events for business processes, and integration events for data synchronization. This can help to align the events with the goals and the expectations of the stakeholders, and to optimize the performance and the consistency of the system.

However, these guidelines are not absolute, and there may be situations where you need to deviate from them. For example, you may need to use integration events within a bounded context if you have multiple subdomains or microservices that need to communicate asynchronously or reliably. Or you may need to use domain events across bounded contexts or external systems if you have a shared kernel or a business partnership that requires a high level of collaboration or coordination. In these cases, you need to weigh the benefits and the costs of using different types of events, and make trade-offs based on your specific context and requirements.

5 How to monitor and adjust the event balance

The balance of domain events and integration events is not static, but rather changes over time. As your system grows and changes, you may need to adjust the event balance to accommodate new scenarios, challenges, or opportunities. Signs that the event balance needs adjusting include changes in the domain model or bounded context boundaries, shifts in business processes or user behavior, modifications to the system architecture or infrastructure, alterations to non-functional requirements or quality attributes, and feedback from the system operation or stakeholders. To monitor and adjust the event balance, various tools and techniques can be used such as event storming or modeling sessions, event logs or streams, event metrics or dashboards, event tests or simulations, and event reviews or retrospectives. These tools and techniques can help identify, analyze, and improve the granularity and frequency of events to meet your system needs and expectations.

6 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?