The patterns we’ve discussed—layered architecture, ports & adapters architecture, and CQRS—should not be treated as systemwide organizational principles. These are not necessarily high-level architecture patterns for a whole bounded context either.

Consider a bounded context encompassing multiple subdomains, as shown in Figure 8-17. The subdomains can be of different types: core, supporting, or generic. Even subdomains of the same type may require different business logic and architec‐ tural patterns (that’s the topic of Chapter 10). Enforcing a single, bounded, context‐ wide architecture will inadvertently lead to accidental complexity.

Figure 8-17. Bounded contexts spanning multiple subdomains

Our goal is to drive design decisions according to the actual needs and business strat‐ egy. In addition to the layers that partition the system horizontally, we can introduce additional vertical partitioning. It’s crucial to define logical boundaries for modules encapsulating distinct business subdomains and use the appropriate tools for each, as demonstrated in Figure 8-18.

Appropriate vertical boundaries make a monolithic bounded context a modular one and help to prevent it from becoming a big ball of mud. As we will discuss in Chap‐ ter 11, these logical boundaries can be refactored later into physical boundaries of finer-grained bounded contexts.

Figure 8-18. Architectural slices