In Domain-Driven Design, a domain is divided into multiple subdomains, each representing a distinct area of business logic. A bounded context provides a technical boundary where a single, consistent model is implemented. While a subdomain focuses on the business problem, a bounded context focuses on its technical implementation, and a single subdomain can be implemented using one or more bounded contexts depending on its complexity.
Context mapping defines how bounded contexts interact. The key strategies are:
- Conformist: The downstream context adopts the upstream model as-is, with no modifications.
- Anticorruption Layer: A translation layer shields the downstream context from adopting the upstream model directly, adapting data as needed.
- Customer-Supplier: The downstream (customer) context depends on services or data provided by the upstream (supplier) context, with potential influence over its design.
- Separate Ways: The contexts have no interaction or dependency and operate independently.
- Shared Kernel: A subset of a model is shared between contexts, requiring careful management of changes.
- Published Language: A shared format (e.g., JSON schema or events) standardizes communication between contexts.
- Open Host Service: A bounded context exposes a service interface (e.g., API) to provide functionality for others.
Conformist and anticorruption layer relationships are mutually exclusive due to their opposing strategies. Customer-supplier and separate ways are also incompatible, as dependency precludes independence. However, some relationships can coexist, such as published language and open host service, where shared formats can underlie exposed functionality.
The anticorruption layer often uses an API to interact with an upstream context but translates the data to fit the downstream model, preventing coupling. Communication between contexts can also occur through events, shared kernels, or shared databases: an APIs are not the only method of interaction.