Map DDD Contexts and Integration Patterns

DDD Context Mapping is a Domain-Driven Design skill for mapping relationships between bounded contexts and defining the integration contracts between them. Its instructions: list all context pairs and the direction of dependency between them; choose a relationship pattern per pair; define translation rules and ownership boundaries; and add failure modes, fallback behavior and a versioning policy.

The output it requires is a relationship map for every context pair, a contract ownership matrix, the translation and anti-corruption decisions made, and known coupling risks with a mitigation plan.

Its reference file, references/context-map-patterns.md, names the standard DDD relationship patterns - Partnership, Shared Kernel, Customer-Supplier, Conformist, Anti-Corruption Layer, Open Host Service and Published Language - and gives a mapping template with columns for upstream context, downstream context, pattern, contract owner and whether translation is needed, illustrated with a Billing-to-Checkout Customer-Supplier row (Billing owns the contract, translation needed) and an Identity-to-Checkout Conformist row (Identity owns it, no translation needed). It also gives an anti-corruption layer checklist: define a canonical domain model for the receiving context, translate external terms into the local ubiquitous language, keep the ACL code at the boundary rather than inside the domain core, and add contract tests for the mapped behavior.

Use it when defining integration patterns between bounded contexts, preventing domain leakage across service boundaries, planning anti-corruption layers during a migration, or clarifying upstream and downstream ownership for contracts. An example request: mapping how a Checkout context integrates with Billing, Inventory and Fraud contexts, including ACL and contract ownership. Do not use it for a single-context system with no integrations, for internal class design alone, or for selecting cloud infrastructure tooling.

Input is the set of bounded contexts and their known or suspected dependencies. Output is the four artifacts listed above: the relationship map, the contract ownership matrix, the translation/ACL decisions, and the coupling-risk mitigation plan. Limitations: this skill does not replace API-level schema design, it does not by itself guarantee organizational alignment, and the map should be revisited when team ownership changes.

It suits architects and teams defining or reviewing how services or bounded contexts integrate, especially during a migration or when clarifying which team owns a shared contract and how translation should happen at the boundary.