As we discussed in Chapter 10, it can be risky to prematurely decompose the system into the smallest bounded contexts possible. We will discuss bounded contexts and microservices in more detail in the next chapter. For now, look for where the most value can be gained by turning the logical boundaries into physical boundaries. The process of extracting a bounded context(s) by turning a logical boundary into a phys‐ ical one is shown in Figure 13-2.

Questions to ask yourself:

• Are multiple teams working on the same codebase? If so, decouple the develop‐ ment lifecycles by defining bounded contexts for each team.

• Are conflicting models being used by the different components? If so, relocate the conflicting models into separate bounded contexts.

Figure 13-2. Extracting a bounded context by turning a logical boundary into a physical boundary

When the minimum required bounded contexts are in place, examine the relation‐ ships and integration patterns between them. See how the teams working on different bounded contexts communicate and collaborate. Especially when they are communi‐ cating through ad hoc or shared-kernel–like integration, do the teams have shared goals and adequate collaboration levels?

Pay attention to problems that the context integration patterns can address:

Customer–supplier relationships

As we discussed in Chapter 11, organizational growth can invalidate prior com‐ munication and collaboration patterns. Look for components designed for a part‐ nership relationship of multiple engineering teams, but where the partnership is no longer sustainable. Refactor to the appropriate type of customer–supplier relationship (conformist, anticorruption layer, or open-host service).

Anticorruption layer

Anticorruption layers can be useful for protecting bounded contexts from legacy systems, especially, when legacy systems are using inefficient models that tend to spread into downstream components.

Another common use case for implementing an anticorruption layer is to protect a bounded context from frequent changes in the public interfaces of an upstream service it uses.

Open-host service

If changes in the implementation details of one component often ripple through the system and affect its consumers, consider making it an open-host service: decouple its implementation model from the public API it exposes.

Separate ways

Especially in large organizations, you may encounter friction among engineering teams resulting from having to collaborate and co-evolve a shared functionality. If the “apple of discord” functionality is not business critical—that is, it’s not a core subdomain—the teams can go their separate ways and implement their own solutions, eliminating the source of friction.