Claude-skill-registry context-mapping
Map relationships between bounded contexts using DDD context mapping patterns. Use when defining upstream/downstream relationships, integration strategies (ACL, OHS, PL), or generating Context Mapper DSL output. Follows event storming for bounded context discovery.
git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/context-mapping" ~/.claude/skills/majiayu000-claude-skill-registry-context-mapping && rm -rf "$T"
skills/data/context-mapping/SKILL.mdContext Mapping Skill
Interactive Mapping Configuration
Use AskUserQuestion to configure the context mapping session:
# Question 1: Mapping Mode (MCP: DDD context mapping methodology) question: "What level of context mapping analysis do you need?" header: "Mode" options: - label: "Full Analysis (Recommended)" description: "Systematically analyze all bounded contexts with CML output" - label: "Quick Overview" description: "Identify obvious relationships only (~3K tokens)" - label: "Guided Discovery" description: "Interactive, confirm each relationship with user" - label: "Pattern Focus" description: "Focus on specific integration patterns (ACL, OHS, etc.)" # Question 2: Relationship Clarity (MCP: DDD upstream/downstream patterns) question: "How clear are the context boundaries?" header: "Clarity" options: - label: "Well-Defined" description: "Bounded contexts identified, need relationship mapping" - label: "Partially Known" description: "Some contexts identified, may discover more" - label: "Exploratory" description: "Start from scratch, discover contexts and relationships" - label: "From Event Storm" description: "Use output from prior event storming session"
Use these responses to select the appropriate mapping mode and calibrate discovery depth.
Map relationships between bounded contexts using Domain-Driven Design context mapping patterns. Produces Context Mapper DSL (CML) output and integration strategy recommendations.
When to Use This Skill
Keywords: context mapping, bounded contexts, upstream, downstream, ACL, anti-corruption layer, shared kernel, customer supplier, open host service, published language, conformist, partnership, CML, integration patterns, domain relationships
Use this skill when:
- After event storming when bounded contexts have been identified
- Defining integration strategies between domains
- Documenting domain relationships and dependencies
- Generating context map diagrams (Mermaid/PlantUML)
- Creating Context Mapper DSL (CML) output
- Planning team boundaries based on context relationships
- Identifying where anti-corruption layers are needed
Context Mapping Patterns
Eight strategic DDD patterns for defining context relationships:
Symmetric Patterns (Equal Relationship)
| Pattern | Abbrev | Description | Use When |
|---|---|---|---|
| Shared Kernel | SK | Shared code/model between contexts | Two contexts need identical domain logic |
| Partnership | P | Equal collaboration, mutual dependency | Teams co-evolve, no clear upstream/downstream |
Asymmetric Patterns (Upstream/Downstream)
| Pattern | Abbrev | Description | Use When |
|---|---|---|---|
| Customer/Supplier | C/S | Upstream supplies, downstream consumes | Clear provider/consumer relationship |
| Conformist | CF | Downstream adopts upstream model | Downstream team has no leverage to negotiate |
| Anti-Corruption Layer | ACL | Downstream translates upstream model | Upstream model doesn't fit downstream needs |
| Open Host Service | OHS | Upstream provides formal API | Multiple consumers need standardized access |
| Published Language | PL | Standardized API format (OpenAPI, etc.) | Cross-team communication requires contract |
No Integration
| Pattern | Abbrev | Description | Use When |
|---|---|---|---|
| Separate Ways | SW | No integration, independent evolution | Contexts have no meaningful relationship |
For detailed pattern descriptions with examples: See references/pattern-catalog.md
Pattern Selection Guide
Decision Flow
Do the contexts share code or data model? ├── Yes → Shared Kernel [SK] └── No → Is there a clear data/service flow? ├── No → Do teams collaborate equally? │ ├── Yes → Partnership [P] │ └── No → Separate Ways [SW] └── Yes → Identify Upstream (provider) and Downstream (consumer) └── Can downstream influence upstream's model? ├── No → Does upstream model fit downstream needs? │ ├── Yes → Conformist [CF] │ └── No → Anti-Corruption Layer [ACL] └── Yes → Customer/Supplier [C/S] └── Does upstream serve multiple consumers? ├── Yes → Add Open Host Service [OHS] │ └── Needs contract? → Add Published Language [PL] └── No → Basic C/S is sufficient
For detailed selection criteria: See references/pattern-selection.md
Context Mapper DSL (CML)
Basic Syntax
ContextMap <MapName> { contains <Context1> contains <Context2> // Asymmetric: Downstream [D] <- Upstream [U] <DownstreamContext> [D,<patterns>]<-[U,<patterns>] <UpstreamContext> // Symmetric: Both sides equal <Context1> [<patterns>]<->[<patterns>] <Context2> }
Notation Reference
| Symbol | Meaning |
|---|---|
| Downstream context |
| Upstream context |
| Asymmetric relationship (upstream to downstream) |
| Symmetric relationship |
| Downstream + Customer |
| Upstream + Supplier |
| Downstream with Anti-Corruption Layer |
| Upstream with Open Host Service + Published Language |
| Shared Kernel (symmetric) |
| Partnership (symmetric) |
| Conformist |
For complete CML syntax: See references/cml-syntax.md
Multi-Mode Execution
Mode Selection
| Mode | Description | Use When |
|---|---|---|
| Systematically analyze all bounded contexts | Comprehensive mapping, larger domains |
| Identify obvious relationships only | Quick overview, small domains |
| Interactive, confirm each relationship | Learning, validation, uncertain relationships |
Full Mode Protocol
- Inventory - List all bounded contexts with aggregates
- Dependency Scan - Identify data flow and service calls
- Pattern Assignment - Apply selection criteria systematically
- CML Generation - Produce complete context map
- Diagram Generation - Create visual representation
- Review Output - Mark uncertain relationships for human review
Quick Mode Protocol
- Context List - Enumerate known bounded contexts
- Obvious Relationships - Map clear upstream/downstream pairs
- Basic CML - Generate minimal context map
- Skip Ambiguous - Flag uncertain relationships for later
Guided Mode Protocol
- Present Context Pair - Show two contexts to user
- Ask Relationship - "Do these contexts interact?"
- Determine Direction - "Which provides data/services?"
- Select Pattern - Present pattern options with explanations
- Confirm - Verify user agrees with classification
- Repeat - Continue for all context pairs
Output Artifacts
1. Context Mapper DSL (CML) File
/* Context Map: <DomainName> * Generated: <date> * Source: Event storming session */ ContextMap <DomainName>Map { contains <Context1> contains <Context2> // ... relationships }
2. Mermaid Diagram
graph LR subgraph "Core Domain" A[Context1] end subgraph "Supporting" B[Context2] end A -->|pattern| B
3. Integration Strategy Report
## Integration Strategies ### <Context1> -> <Context2> - **Pattern:** Customer/Supplier - **Direction:** Context1 (upstream) supplies Context2 (downstream) - **Rationale:** <why this pattern> - **Implementation:** <technical approach> - **Team Impact:** <organizational considerations>
4. Team Topology Suggestions
Based on context relationships, suggest team boundaries following Team Topologies patterns (Stream-aligned, Platform, Enabling, Complicated Subsystem).
For team topology guidance: See references/team-topologies.md
Integration with Event Storming
Input from Event Storming
Context mapping consumes:
- Bounded Contexts - Named domain boundaries with primary aggregates
- Domain Events - Events that cross context boundaries
- Commands - Operations that trigger cross-context communication
- Actors - Users/systems that interact with multiple contexts
Workflow Integration
Domain Storytelling ↓ (understand business flow) Event Storming ↓ (discover bounded contexts) Context Mapping ← YOU ARE HERE ↓ (define relationships) Modular Architecture ↓ (implement structure) Fitness Functions (enforce boundaries)
Cross-Context Event Identification
When mapping contexts, identify:
- Events crossing boundaries - Indicate integration needs
- Shared aggregates - Potential Shared Kernel candidates
- Translation requirements - ACL candidates
- API contracts - OHS/PL candidates
Integration Strategies
For each pattern, there's a recommended technical implementation:
| Pattern | Implementation Strategy |
|---|---|
| Shared Kernel | Shared NuGet package, common project reference |
| Customer/Supplier | Internal API, MediatR notifications |
| Anti-Corruption Layer | Adapter pattern, translation service |
| Open Host Service | REST API, gRPC service |
| Published Language | OpenAPI spec, Protobuf definitions |
| Partnership | Shared event bus, bilateral contracts |
| Conformist | Direct model adoption, no translation |
| Separate Ways | No integration code needed |
For detailed implementation guidance: See references/integration-strategies.md
Example Output
E-Commerce Domain Context Map
/* Context Map: E-Commerce Platform * Generated: 2025-01-15 * Bounded Contexts from event storming session */ ContextMap ECommercePlatform { contains OrderContext contains InventoryContext contains PaymentContext contains ShippingContext contains CustomerContext /* Order consumes inventory availability * Inventory owns stock truth, Order queries it */ OrderContext [D,C]<-[U,S] InventoryContext /* Payment isolates external gateway * Gateway has foreign model, needs translation */ PaymentContext [D,ACL]<-[U,OHS,PL] ExternalPaymentGateway /* Order and Shipping co-evolve * Both teams collaborate on fulfillment flow */ OrderContext [P]<->[P] ShippingContext /* Customer data shared * CustomerInfo value object used by multiple contexts */ OrderContext [SK]<->[SK] CustomerContext ShippingContext [SK]<->[SK] CustomerContext }
Honest Limitations
What This Skill Does Well
- Systematic pattern identification from bounded contexts
- CML syntax generation for Context Mapper tooling
- Integration strategy recommendations based on patterns
- Team topology alignment suggestions
- Mermaid/PlantUML diagram generation
What Requires Human Input
- Team dynamics - Actual organizational politics and relationships
- Business priorities - Which integrations matter most
- Legacy constraints - Existing systems that limit options
- Change appetite - Organizational readiness for restructuring
- Trade-off decisions - When multiple patterns could work
All outputs clearly distinguish recommendations from requirements and flag uncertain classifications for human review.
Related Skills
- event-storming - Discover bounded contexts (prerequisite)
- domain-storytelling - Understand business flow (optional prerequisite)
- modular-architecture - Implement module structure (next step)
- adr-management - Document integration decisions
- architecture-documentation - Generate architecture diagrams
References
- Pattern Catalog - All 8 patterns with examples
- CML Syntax - Context Mapper DSL reference
- Pattern Selection - Decision guide
- Integration Strategies - Technical implementation
- Team Topologies - Organizational alignment
Version History
- v1.0.0 (2025-12-22): Initial release - Context mapping patterns, CML output, multi-mode execution
Last Updated: 2025-12-22 Model: claude-opus-4-5-20251101