context-mapping

What this skill does

# Context Mapping Skill

## Interactive Mapping Configuration

Use AskUserQuestion to configure the context mapping session:

```yaml
# 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](references/pattern-catalog.md)

## Pattern Selection Guide

### Decision Flow

```text
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](references/pattern-selection.md)

## Context Mapper DSL (CML)

### Basic Syntax

```cml
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](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

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

```cml
/* Context Map: <DomainName>
 * Generated: <date>
 * Source: Event storming session
 */

ContextMap <DomainName>Map {
    contains <Context1>
    contains <Context2>
    // ... relationships
}
```

### 2. Mermaid Diagram

```mermaid
graph LR
    subgraph "Core Domain"
        A[Context1]
    end
    subgraph "Supporting"
        B[Context2]
    end
    A -->|pattern| B
```

### 3. Integration Strategy Report

```markdown
## 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 Subs