Tactical DDD — Rich Domain Modeling
Workflow
Determine the user's intent first:
| Intent | Phases to run |
|---|---|
| "validate / review / check / is this correct?" | Phase 1 + 2 only → report findings, ask before refactoring |
| "fix / refactor / improve / clean up" | Phase 1 + 2 + 3 |
| "how should I design / model this?" | Load reference.md directly |
Phase 1 — Detect
Load detection.md and scan the target code for anemia signals. Produce a severity score and list of affected classes.
Phase 2 — Assess
For each affected class, determine the correct building block:
| Has unique identity tracked over time? | Has invariants tying multiple objects? | → Building Block |
|---|---|---|
| Yes | — | Entity |
| No | — | Value Object |
| Yes (root) + children with shared invariants | Yes | Aggregate |
| Operation spans multiple Aggregates/doesn't belong to any | — | Domain Service |
Prefer Value Objects over Entities. Prefer small Aggregates over large ones.
If intent was validate/review: stop here. Report findings using the output format below. Ask "Would you like me to apply these fixes?" before proceeding.
Phase 3 — Refactor
Load refactoring.md for step-by-step moves. Apply in this order:
- Replace setter chains with a single expressive method
- Move service logic into the Aggregate that owns it
- Add business guards at the top of each method
- Publish a Domain Event after each successful state change
- Replace primitive types with Value Objects
For deep pattern questions (boundary design, event modeling, service vs. entity decision), load reference.md.
Quick Anemia Signals (scan first)
public setX() / public setY() → behaviour should be encapsulated service.doX(entity, ...) → logic likely belongs in entity entity.setA(); entity.setB(); ... → setter chain = missing intent method no domain methods beyond getters → pure data bag
Golden Rules
- Behaviour with data — Objects own both state and the operations that change it
- Ubiquitous Language — Method names come from the domain, not CRUD (
commitTo, notsetStatus) - Small Aggregates — Root + Value Objects by default; add child Entities only for true invariants
- One transaction = one Aggregate — Cross-Aggregate rules use eventual consistency via Domain Events
- Reference by ID — Never hold object references to other Aggregates
- Value Objects first — Use Entities only when individual identity is essential
- Domain Services sparingly — Excessive services → anemic model
- Protect invariants — The Aggregate is the last line of defence; never trust the caller
Output Format
When reviewing code, report:
## Anemia Diagnosis: <ClassName> Severity: [None | Mild | Moderate | Severe] Issues: - <description of problem> Recommended refactoring: - <specific move from refactoring.md>
When refactoring, show a before/after diff for each class touched.
