Tactical Ddd

Tactical DDD — Rich Domain Modeling

Workflow

Determine the user's intent first:

Phase 1 — Detect

Load detection.md [blocked] 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:

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 [blocked] for step-by-step moves. Apply in this order:

1. Replace setter chains with a single expressive method
2. Move service logic into the Aggregate that owns it
3. Add business guards at the top of each method
4. Publish a Domain Event after each successful state change
5. Replace primitive types with Value Objects

For deep pattern questions (boundary design, event modeling, service vs. entity decision), load reference.md [blocked].

Quick Anemia Signals (scan first)

public setX() / public setY()        → behaviour should be encapsulatedservice.doX(entity, ...)              → logic likely belongs in entityentity.setA(); entity.setB(); ...     → setter chain = missing intent methodno domain methods beyond getters      → pure data bag

Golden Rules

1. Behaviour with data — Objects own both state and the operations that change it
2. Ubiquitous Language — Method names come from the domain, not CRUD (commitTo, not setStatus)
3. Small Aggregates — Root + Value Objects by default; add child Entities only for true invariants
4. One transaction = one Aggregate — Cross-Aggregate rules use eventual consistency via Domain Events
5. Reference by ID — Never hold object references to other Aggregates
6. Value Objects first — Use Entities only when individual identity is essential
7. Domain Services sparingly — Excessive services → anemic model
8. 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.