Context Map Command

Map relationships between bounded contexts using DDD context mapping patterns. Typically follows event storming to define integration strategies between discovered contexts.

Arguments

• [bounded-contexts-file]: Optional path to file containing bounded contexts (e.g., event storming output)

• --mode: Analysis mode (default: guided)

  • full: Systematic analysis of all relationships (~10K tokens)
  • quick: Identify obvious patterns only (~3K tokens)
  • guided: Interactive, confirm each relationship (variable)

• --output: Output format (default: both)

  • cml: Context Mapper DSL file only
  • diagram: Mermaid diagram only
  • both: Both CML and diagram

• --input-dir: Directory to search for event storming output (default: docs/event-storming/)

• --dir: Output directory for context map (default: docs/architecture/)

Execution

Step 1: Parse Arguments

Extract bounded contexts source, mode, and output format from arguments.

If no source provided:

1. Check for recent event storming output in docs/event-storming/
2. Check for bounded context definitions in docs/architecture/
3. If none found, ask user: "Please provide bounded contexts to map. Options:
   • Path to an event storming output file
   • Path to a bounded context definition file
   • List the bounded context names directly"

Default mode is guided. Default output is both.

Step 2: Load Context Mapping Skill

Invoke the context-mapping skill to access:

• Pattern catalog (SK, C/S, ACL, OHS, PL, CF, P, SW)
• CML syntax reference
• Pattern selection decision trees
• Team topology alignment guidance

Step 3: Inventory Bounded Contexts

Parse the input to extract bounded contexts:

For each bounded context, capture:
- Name
- Primary purpose/responsibility
- Core aggregates (if known)
- Domain events published (if known)
- Domain events consumed (if known)
- Team ownership (if known)

If input lacks detail, use Glob/Grep to discover additional context from:

• Module/package structure
• API definitions
• Database schemas
• Event storming artifacts

Step 4: Execute Based on Mode

Full Mode (Systematic Analysis)

Spawn the context-mapper agent for comprehensive analysis:

Analyze these bounded contexts and map all relationships:

[List of bounded contexts with details]

Requirements:
1. Identify all communication patterns between contexts
2. Determine upstream/downstream for each relationship
3. Select appropriate pattern (SK, C/S, ACL, OHS, PL, CF, P, SW)
4. Provide rationale for each pattern choice
5. Suggest team topology alignment
6. Generate CML output with detailed comments

The agent will:

• Analyze data and event flows
• Apply pattern selection criteria
• Generate comprehensive CML with rationale
• Suggest team structures

Quick Mode (Obvious Patterns)

Perform rapid analysis without spawning agent:

1. Identify obvious relationships from:
   • Event publishing/consuming pairs
   • Direct API dependencies
   • Shared data access
2. Apply default patterns:
   • Event-driven → Customer/Supplier
   • External systems → ACL
   • Shared libraries → Shared Kernel candidates
3. Mark ambiguous relationships for later review
4. Generate minimal CML without detailed rationale

Guided Mode (Interactive)

Work interactively through relationships:

For each pair of contexts that might relate:

1. Present context pair: "Let's examine the relationship between [A] and [B]"
2. Show evidence: Display any discovered dependencies (events, APIs, shared data)
3. Ask direction: "Which context is upstream (provides) vs downstream (consumes)?"
4. Suggest pattern: Recommend a pattern based on evidence
5. Confirm or override: Let user accept, modify, or skip
6. Capture rationale: Document why this pattern was chosen

After all relationships mapped, generate CML.

Step 5: Generate Output Artifacts

CML Output

/* Context Map: [System/Domain Name]
 * Generated: [ISO Date]
 * Mode: [full|quick|guided]
 * Source: [Input file or "Interactive"]
 */

ContextMap [SystemName]Map {
    // Bounded Context Declarations
    contains [Context1]
    contains [Context2]
    // ...

    /* [Context1] ← [Context2]
     * Pattern: Customer/Supplier
     * Direction: Context2 supplies data to Context1
     * Rationale: [Why this pattern fits]
     */
    [Context1] [D,C]<-[U,S] [Context2]

    // ... more relationships
}

Mermaid Diagram

graph LR
    subgraph "Core Domain"
        A[Context1]
    end

    subgraph "Supporting"
        B[Context2]
        C[Context3]
    end

    subgraph "Generic"
        D[Context4]
    end

    B -->|"Supplier"| A
    A <-->|"Partnership"| C
    D -.->|"ACL"| A

Summary Report

## Context Map Summary

**System:** [Name]
**Date:** [ISO Date]
**Contexts Mapped:** N
**Relationships Defined:** M

### Pattern Distribution

| Pattern | Count | Contexts |
|---------|-------|----------|
| Customer/Supplier | X | A→B, C→D |
| Partnership | Y | E↔F |
| ACL | Z | G←External |

### Team Topology Suggestions

Based on the context map, consider:
- **Stream-aligned teams**: [Contexts with clear ownership]
- **Platform team candidates**: [Contexts serving multiple consumers]
- **Shared Kernel review**: [Contexts that might merge or split]

### Integration Priorities

1. [High-priority integration point]
2. [Medium-priority integration point]
3. [Low-priority integration point]

### Next Steps

- [ ] Review ACL boundaries for external integrations
- [ ] Create ADRs for pattern decisions
- [ ] Align team structure with topology suggestions

Step 6: Save Results

Save outputs based on format flag:

CML file:

• docs/architecture/context-map.cml

Mermaid diagram:

• Embed in docs/architecture/context-map.md

Summary report:

• Append to context-map.md or create separate summary

Use --dir to specify a custom output directory.

Step 7: Suggest Follow-Up Actions

After generating the context map:

## Suggested Next Steps

1. **Architecture Documentation**: Use `/ea-document component` to document each bounded context
2. **ADRs**: Use `/adr-create` to document pattern decisions
3. **Fitness Functions**: Use `/fitness-check` to create tests for module boundaries
4. **Team Alignment**: Review Team Topologies suggestions with stakeholders