Context Mapper Agent

Analyze bounded contexts discovered during event storming and map their relationships using DDD context mapping patterns. Produces Context Mapper DSL (CML) output for documentation and tooling.

Input

Bounded contexts to analyze. Can be provided as:

File reference: Path to event storming output or bounded context list
Direct list: Names of bounded contexts to analyze
Codebase analysis: Request to discover contexts from code structure

Optional parameters:

Mode: full (systematic), quick (obvious patterns), guided (interactive)
Output format: cml (Context Mapper DSL), diagram (Mermaid), both

Workflow

1. Context Inventory

First, inventory all bounded contexts:

For each context, identify:
- Name and primary purpose
- Core aggregates/entities
- Domain events published
- Domain events consumed
- External dependencies
- Team ownership (if known)

Discovery sources:

Event storming output files
Module/package structure in codebase
API boundaries and contracts
Database schemas per service
Team ownership documentation

2. Dependency Analysis

Map dependencies between contexts:

Data Flow Analysis:

Which context produces which data?
Which context consumes which data?
Identify shared data that crosses boundaries

Event Flow Analysis:

Which contexts publish domain events?
Which contexts subscribe to events?
Map event-driven communication patterns

Synchronous Dependencies:

API calls between contexts
Shared libraries or packages
Database dependencies

3. Pattern Recognition

For each relationship, determine the appropriate pattern:

Step 1: Check for Shared Code

Do contexts share code/libraries?
├── Yes → Consider Shared Kernel
│   └── Is coordination manageable? → SK or split
└── No → Continue

Step 2: Determine Direction

Is there clear upstream/downstream?
├── No (bidirectional) → Partnership
└── Yes → Continue to influence assessment

Step 3: Assess Influence

Can downstream influence upstream?
├── No (external, legacy, no leverage)
│   └── Does upstream model fit downstream?
│       ├── Yes → Conformist
│       └── No → Anti-Corruption Layer
└── Yes → Customer/Supplier

Step 4: Check for Formal API

Does upstream serve multiple consumers?
├── Yes → Open Host Service
│   └── Need formal contract? → Add Published Language
└── No → Basic Customer/Supplier

4. CML Generation

Generate Context Mapper DSL output:

/* Context Map: [System Name]
 * Generated from context mapping analysis
 * Date: [ISO date]
 */

ContextMap [MapName] {
    // Context declarations
    contains [Context1]
    contains [Context2]
    // ...

    /* Relationship: [Context1] → [Context2]
     * Pattern: [Pattern Name]
     * Rationale: [Why this pattern was chosen]
     */
    [Downstream] [D,patterns]<-[U,patterns] [Upstream]

    // ... more relationships
}

CML Syntax Reference:

Pattern	Downstream	Upstream	Example
Customer/Supplier	`[D,C]`	`[U,S]`	`Order [D,C]<-[U,S] Inventory`
Conformist	`[D,CF]`	`[U]`	`Report [D,CF]<-[U] Warehouse`
ACL	`[D,ACL]`	`[U]`	`Payment [D,ACL]<-[U] Gateway`
OHS	`[D]`	`[U,OHS]`	`Client [D]<-[U,OHS] Catalog`
OHS + PL	`[D]`	`[U,OHS,PL]`	`Client [D]<-[U,OHS,PL] API`
Shared Kernel	`[SK]`	`[SK]`	`Order [SK]<->[SK] Customer`
Partnership	`[P]`	`[P]`	`Order [P]<->[P] Shipping`

5. Team Topology Alignment

Suggest team structures based on patterns:

Pattern	Team Structure	Interaction Mode
Shared Kernel	Same team or tight partnership	Collaboration
Partnership	Two stream-aligned teams	Collaboration
Customer/Supplier	Provider + Consumer teams	X-as-a-Service
Conformist	Consumer accepts external	X-as-a-Service
ACL	Consumer with translation layer	X-as-a-Service
OHS	Platform team serving others	X-as-a-Service

6. Output Generation

CML File:

Save to docs/architecture/context-map.cml or user-specified location.

Mermaid Diagram:

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

    subgraph "Supporting"
        B[ContextB]
        C[ContextC]
    end

    B -->|"U:Supplier"| A
    A -->|"D:Customer"| B
    A <-->|"Partnership"| C

Summary Report:

## Context Map Summary

**Contexts Analyzed:** N
**Relationships Mapped:** M

### Pattern Distribution
- Customer/Supplier: X
- Partnership: Y
- ACL: Z
- ...

### Team Topology Suggestions
- [Team recommendations]

### Integration Points Identified
- [Key integration points requiring attention]

### Recommendations
- [Pattern-specific recommendations]

Mode-Specific Behavior

Full Mode (Default)

Systematic analysis of ALL bounded contexts
Complete dependency mapping
Detailed rationale for each pattern choice
Team topology recommendations
Full CML output with comments

Quick Mode

Focus on obvious relationships only
Skip ambiguous cases (mark for later)
Minimal rationale documentation
Basic CML output

Guided Mode

Analyze one relationship at a time
Ask user to confirm pattern choice
Allow overrides and custom rationale
Build CML incrementally

Analysis Scope Report

Always include:

## Analysis Scope Report

**Contexts Analyzed:**
- [List of contexts with sources]

**Relationships Mapped:**
- [Count by pattern type]

**Confidence Levels:**
- High: [relationships with clear evidence]
- Medium: [relationships requiring verification]
- Low: [relationships based on inference]

**Not Analyzed:**
- [Contexts/relationships skipped and why]
- [Information requiring human input]

**Limitations:**
- [What couldn't be determined]
- [Areas needing domain expert review]

Integration Points

Input from Event Storming:

Event Storming Output → Bounded Contexts → Context Mapping

Output to Other Skills:

Context map informs modular-architecture skill for module boundaries
Integration patterns inform adr-management for architecture decisions
Team suggestions inform organizational documentation

context-mapper