Domain Modeling Skill
Use this skill as a tactical domain-model review lens. Always load
review-verification-protocol
before reporting findings. For repository change reviews, also load
code-review.
Use domain-driven-design when the primary
task is discovering or implementing a model rather than reviewing one.
Workflow
- Identify the bounded context, ubiquitous language, business rules, and
lifecycle boundaries represented by the code.
- Review entities, value objects, aggregates, repositories, services, and
events against those rules rather than against pattern names alone.
- Verify consistency boundaries, ownership, identity, state transitions, and
whether domain APIs protect invariants.
- Look for primitive obsession, anemic behavior, invalid intermediate states,
and DTO, framework, or persistence leakage.
- Confirm that suggested modeling complexity is justified. Record missing
evidence, skipped validation, and residual domain risk.
Output
Map verified issues to domain concepts, affected files, business risk, the
smallest useful refactor, skipped validation, and residual risk.
1---2name: domain-modeling3description: Review tactical DDD models, aggregates, entities, value objects, invariants, domain services, and ubiquitous language. Use for a focused audit of an existing domain model; do not use to design a new model or force DDD onto simple data-centric work.4---56# Domain Modeling Skill78Use this skill as a tactical domain-model review lens. Always load9[`review-verification-protocol`](../review-verification-protocol/SKILL.md)10before reporting findings. For repository change reviews, also load11[`code-review`](../code-review/SKILL.md).1213Use [`domain-driven-design`](../domain-driven-design/SKILL.md) when the primary14task is discovering or implementing a model rather than reviewing one.1516## Workflow17181. Identify the bounded context, ubiquitous language, business rules, and19 lifecycle boundaries represented by the code.202. Review entities, value objects, aggregates, repositories, services, and21 events against those rules rather than against pattern names alone.223. Verify consistency boundaries, ownership, identity, state transitions, and23 whether domain APIs protect invariants.244. Look for primitive obsession, anemic behavior, invalid intermediate states,25 and DTO, framework, or persistence leakage.265. Confirm that suggested modeling complexity is justified. Record missing27 evidence, skipped validation, and residual domain risk.2829## Output3031Map verified issues to domain concepts, affected files, business risk, the32smallest useful refactor, skipped validation, and residual risk.
nledford