Integrating Bounded Contexts - Mini-workshop
2 likes•1,881 views
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".
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
- 7. PARTNERSHIP ➤ Succeed or fail together.
- 8. SHARED KERNEL ➤ Share part of the model.
- 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.