Decoupled Communication in Applications

Bounded contexts consist of data and code. Each bounded context has its own set of data and codes it encapsulates. Bounded contexts communicate with each other using events, enabling decoupled communication. They can consume and store the necessary data, duplicating it if needed. Typically, different contexts only require specific portions of the data. It is essential to make the communication engaging and comprehensive. Events serve as the interface for communication within an application. By publishing domain events, the interface is established. Events possess attributes that allow us to understand what occurred and react accordingly.

Events create a trackable sequence of facts that contribute to the current state. As the publisher, you know of the main events, including their names and attributes, which allows you to comprehend what happened. If you examine the data, you may question why it is structured a certain way and what led to it. Preventing issues on the consumer side is achieved through inversion of control. Data remains private, and the publisher provides the interface for consuming applications. This emphasizes the importance of ensuring compatibility with the consumers.

Think of domain events as facts. They express the intention of what occurred through their names, such as “The user registered by email” or “The user joined Facebook.” When domain events are published, they serve as the interface between modules. Domain events function as the means of communication in an application.

Data is private, and publishers expose their demands through a public interface for communication. Consumers can store the necessary data in their context, even duplicating it if required. However, typically, other contexts only require specific information. If you examine the data, you may question why it is structured a certain way and what led to it. As the publisher, you know of the main events, including their names and attributes, which allows you to comprehend what occurred. Preventing issues on the consumer side is achieved through inversion of control. Ensuring compatibility with the consumers is crucial.

Promoting business concepts through the code base is vital for modeling a domain. It is essential to focus on the business process and how things flow within the system rather than solely on the technical platform. Bounded contexts are fundamental to domain-driven design. Each bounded context has a core domain, which is explored further. These models did not previously exist; they were developed to accomplish tasks effectively. Sometimes, even within the model, there is a need for a sub-model. With Domain-driven design, we iterate and explore different models until we find the most suitable one. Structural patterns should not be the primary focus. Instead, DDD emphasizes modeling a ubiquitous language within each bounded context. Domain-driven design aims to create a shared understanding of concepts within a specific domain.

[¹]: Domain-Driven Design: Tackling Complexity in the Heart of Software