The document discusses integrating bounded contexts to model subdomains in a domain. It recommends that a bounded context ideally models only one subdomain and describes several organizational and integration patterns for relating bounded contexts, including partnership, shared kernel, customer-supplier, conformist, anticorruption layer, open host service, published language, and separate ways. The goal is to clearly separate models with boundaries rather than having them all merged into a "big ball of mud".

1. INTEGRATING BOUNDED CONTEXTS
Mini-workshop

3. THE DOMAIN == THE PROBLEM SPACE
➤ Domain is divided into subdomains:
➤ Core domain
➤ Supporting subdomain(s)
➤ Generic subdomain(s)

4. BOUNDED CONTEXTS == THE SOLUTION SPACE
➤ Think “application” instead
➤ Ideally, a bounded context models no more than one
subdomain
subdomain
bounded
context

6. ORGANIZATIONAL &
INTEGRATION PATTERNS

7. PARTNERSHIP
➤ Succeed or fail together.

8. SHARED KERNEL
➤ Share part of the model.

9. CUSTOMER-SUPPLIER
➤ Upstream-downstream relationship.

10. CONFORMIST
➤ Same as customer-development, but without cooperation.

11. ANTICORRUPTION LAYER
➤ Provide functionality of the upstream system in terms of your
own model.

12. OPEN HOST SERVICE
➤ There is a (generic) service which can be used by other
bounded contexts.

13. PUBLISHED LANGUAGE
➤ A well-documented, shared language, to allow for translation
between models from different contexts.

14. SEPARATE WAYS
➤ A bounded context has no relation with other contexts.

15. BIG BALL OF MUD
➤ When models aren’t clearly separated by context boundaries.