Context 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)

Asymmetric Patterns (Upstream/Downstream)

No Integration

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

For complete CML syntax: See references/cml-syntax.md

Multi-Mode Execution

Mode Selection

Full Mode Protocol

1. Inventory – List all bounded contexts with aggregates
2. Dependency Scan – Identify data flow and service calls
3. Pattern Assignment – Apply selection criteria systematically
4. CML Generation – Produce complete context map
5. Diagram Generation – Create visual representation
6. Review Output – Mark uncertain relationships for human review

Quick Mode Protocol

1. Context List – Enumerate known bounded contexts
2. Obvious Relationships – Map clear upstream/downstream pairs
3. Basic CML – Generate minimal context map
4. Skip Ambiguous – Flag uncertain relationships for later

Guided Mode Protocol

1. Present Context Pair – Show two contexts to user
2. Ask Relationship – “Do these contexts interact?”
3. Determine Direction – “Which provides data/services?”
4. Select Pattern – Present pattern options with explanations
5. Confirm – Verify user agrees with classification
6. 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:

1. Events crossing boundaries – Indicate integration needs
2. Shared aggregates – Potential Shared Kernel candidates
3. Translation requirements – ACL candidates
4. API contracts – OHS/PL candidates

Integration Strategies

For each pattern, there’s a recommended technical implementation:

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