ddd-context-mapping

name	ddd-context-mapping
description	Derive and enforce DDD boundaries for work units, including bounded contexts, ubiquitous language, aggregates, and invariants. Use when decomposing RFCs/PRDs, planning implementation slices, or reviewing architecture drift in agentic workflows.

DDD Context Mapping

Define domain boundaries before code changes so agents can parallelize safely without model drift. 1. Read RFC/PRD scope and identify business capabilities. 2. Partition capabilities into bounded contexts with minimal overlap. 3. For each context, define ubiquitous language terms. 4. Define non-negotiable invariants and failure modes. 5. Map each work unit to one primary bounded context. 6. Reject units spanning multiple contexts unless explicitly required. - Name bounded contexts with domain terms, not technical layers. - Encode invariants as testable statements. - Keep language consistent across prompts, tests, and code. - Do not mix unrelated domains in one unit. - Do not accept vague invariants such as "should work". - Do not invent new terms when a domain term already exists. | Symptom | Cause | Fix | |---|---|---| | Frequent merge conflicts across units | Boundaries are split by file type, not domain | Re-slice units by bounded context | | Conflicting terminology in code/tests | Ubiquitous language not defined | Add glossary to unit metadata and enforce in reviews | | Regressions in core rules | Invariants implicit only | Encode invariants in tests and review checklist |