Map DDD Contexts and Integration Patterns

DDD Context Mapping defines integration patterns between bounded contexts: it lists all context pairs and their dependency direction, chooses a relationship pattern per pair, defines translation rules and ownership boundaries, and adds failure modes, fallback behavior, and a versioning policy. Output is a fixed set of artifacts - a relationship map for all context pairs, a contract ownership matrix, translation and anti-corruption-layer decisions, and known coupling risks with a mitigation plan. A representative invocation:

Use @ddd-context-mapping to define how Checkout integrates with Billing,
Inventory, and Fraud contexts, including ACL and contract ownership.

Use this skill 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. Don't use it for a single-context system with no integrations, for internal class design alone, or when selecting cloud infrastructure tooling. It explicitly does not replace API-level schema design, does not guarantee organizational alignment by itself, and should be revisited whenever team ownership changes. Detailed mapping structures are available in a companion references/context-map-patterns.md file.

Input is the set of bounded contexts in a system and their dependencies; output is a context map - relationship patterns per context pair, a contract ownership matrix, anti-corruption-layer and translation decisions, and a coupling-risk mitigation plan.

Architects and teams defining how bounded contexts integrate - especially during a migration or when clarifying contract ownership - who need a structured context map rather than ad hoc integration decisions.