Consider the system shown in Figure 15-5.

The CRM bounded context is implemented as an event-sourced domain model. When the CRM system had to be integrated with the Marketing bounded context, the teams decided to leverage the event-sourced data model’s flexibility and let the con‐ sumer—in this case, Marketing—subscribe to the CRM’s domain events and use them to project the model that fits their needs.

When the AdsOptimization bounded context was introduced, it also had to process the information produced by the CRM bounded context. Again, the teams decided to let AdsOptimization subscribe to all domain events produced in the CRM and project the model that fits AdsOptimization’s needs.

Figure 15-5. Strongly coupled distributed system

Interestingly, both the Marketing and AdsOptimization bounded contexts had to present the customers’ information in the same format, and hence ended up projec‐ ting the same model out of the CRM’s domain events: a flattened snapshot of each customer’s state.

The Reporting bounded context subscribed only to a subset of domain events pub‐ lished by the CRM and used as event notification messages to fetch the calculations performed in the AdsOptimization context. However, since both AdsOptimization bounded contexts use the same events to trigger their calculations, to ensure that the Reporting model is updated the AdsOptimization context introduced a delay. It pro‐ cessed messages five minutes after receiving them.

This design is terrible. Let’s analyze the types of coupling in this system.