Document DDD Skill
Generate or update Domain-Driven Design documentation to keep it in sync with the current codebase. All documentation is maintained in a single DOMAIN.md file at the project root.
Execution Flow
Assess current state: Check if
DOMAIN.mdalready exists. Read the codebase to understand the current domain model.Generate/update
DOMAIN.mdwith the following sections:Context Map:
- List all bounded contexts discovered in the codebase
- Document relationships between contexts (upstream/downstream, shared kernel, anti-corruption layer, etc.)
- Note integration patterns used
Glossary:
- Canonical list of ubiquitous language terms with definitions
- Update from current code — add new terms, remove obsolete ones, fix inconsistencies
Aggregates:
- One section per aggregate root
- Document: purpose, invariants, entities contained, value objects, domain events emitted
- Include key code references
Diff and confirm: Before writing, show the user what will be created or changed. Apply changes only after approval.
Output Format
A single file DOMAIN.md at the project root with the following structure:
# Domain Model
## Context Map
...
## Glossary
| Term | Definition | Code Location |
|------|------------|---------------|
| ... | ... | ... |
## Aggregates
### <Aggregate Name>
- **Purpose**: ...
- **Invariants**: ...
- **Entities**: ...
- **Value Objects**: ...
- **Domain Events**: ...
...
Guidelines
- Keep documentation concise and developer-focused — not academic.
- Reference actual code paths so docs stay grounded.
- If
DOMAIN.mdalready exists, update it incrementally rather than replacing wholesale. - Always ask for user confirmation before writing files.