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)

| 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 | | ------ | ------- | | [D] | Downstream context | | [U] | Upstream context | | <- | Asymmetric relationship (upstream to downstream) | | <-> | Symmetric relationship | | [D,C] | Downstream + Customer | | [U,S] | Upstream + Supplier | | [D,ACL] | Downstream with Anti-Corruption Layer | | [U,OHS,PL] | Upstream with Open Host Service + Published Language | | [SK] | Shared Kernel (symmetric) | | [P] | Partnership (symmetric) | | [CF] | Conformist |

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

Multi-Mode Execution

Mode Selection

| Mode | Description | Use When | | ---- | ----------- | -------- | | full | Systematically analyze all bounded contexts | Comprehensive mapping, larger domains | | quick | Identify obvious relationships only | Quick overview, small domains | | guided | 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