A change in a subdomain’s type directly affects its bounded context and, conse‐ quently, corresponding strategic design decisions. As you learned in Chapter 4, differ‐ ent bounded context integration patterns accommodate the different subdomain types. The core subdomains have to protect their models by using anticorruption lay‐ ers and have to protect consumers from frequent changes in the implementation models by using published languages (OHS).

Another integration pattern that is affected by such changes is the separate ways pat‐ tern. As you saw earlier, teams can use this pattern for supporting and generic subdo‐ mains. If the subdomain morphs into a core subdomain, duplicating its functionality by multiple teams is no longer acceptable. Hence, the teams have no choice but to integrate their implementations. The customer–supplier relationship will make the most sense in this case, since the core subdomain will only be implemented by one team.

From an implementation strategy standpoint, core and supporting subdomains differ in how they can be implemented. Supporting subdomains can be outsourced or used as “training wheels” for new hires. Core subdomains must be implemented in-house, as close as possible to the sources of domain knowledge. Therefore, when a support‐ ing subdomain turns into a core subdomain, its implementation should be moved in- house. The same logic works the other way around. If a core subdomain turns into a supporting subdomain, it’s possible to outsource the implementation to let the in- house R&D teams concentrate on the core subdomains.