ddd-refactor

One-line summary

Sequence a refactor toward DDD: identify the smell, name the target pattern, propose small behavior-preserving steps in order.

When to use this skill

• Existing code that the user already considers a problem.
• The user knows roughly which direction to refactor in.
• Migration of a legacy module toward a DDD model.

When NOT to use this skill

• The user just wants a review and isn't ready to refactor → route to ddd-review.
• The user is starting a new domain model from scratch → route to ddd-design.

Core content

The general pattern: name the smell, name the target shape, write small steps that preserve behavior, run tests between each step, commit after each.

Common refactors and their step sequences:

Anemic model → behavioral entity. (1) Pick one operation currently done by a service. (2) Move it onto the entity, keeping the same signature. (3) Have the service delegate to the new entity method. (4) Inline the service call where it is the only caller. Repeat per operation.

Primitive obsession → value object. (1) Introduce the new value object type with a private constructor and a validating factory. (2) Add a single conversion point at the boundary (input parsing). (3) Replace one usage at a time, deepest-first. (4) Stop allowing the primitive at the public API. See ddd-value-object.

God aggregate → multiple aggregates. (1) List the entities currently inside it. (2) For each pair, ask "must these change in the same transaction?" — group by yes-answers. (3) Identify the root of each group. (4) Replace cross-group object references with ID references. (5) Move cross-group consistency to events. See ddd-aggregate.

Leaky repository → domain repository interface. (1) Define a domain-layer interface with methods named in the ubiquitous language. (2) Implement it in the infra layer, wrapping the existing persistence. (3) Switch one caller at a time. (4) Delete the leaked types from the domain layer. See ddd-repository.

Big ball of mud → first bounded context. (1) Pick the most painful seam. (2) Draw the intended boundary on paper. (3) Introduce an anticorruption layer at the seam. (4) Move code across the seam one type at a time. See ddd-context-mapping for the seam's pattern.

Decision heuristics

• Never combine a refactor commit with a feature commit. They review separately, they revert separately.
• Each step must keep behavior identical. The test suite is your seatbelt; if it doesn't exist, write characterization tests first.
• Stop after each step long enough to run tests and commit.
• Big-bang rewrites lose users' trust and almost always grow scope. Prefer ten small refactors over one large one.

Anti-patterns

• Big-bang rewrite with no incremental milestones.
• Refactoring without a test net.
• Renaming classes "to sound DDD" without changing their structure or responsibilities.
• Refactoring and adding features in the same change.

See also

• ddd-anti-patterns — the smells that motivate each refactor.
• ddd-aggregate, ddd-value-object, ddd-bounded-context, ddd-repository — target shapes.
• ddd-deeper-insight — what to do after the obvious refactors are done.

References

• Evans, Domain-Driven Design (2003), Part III (Chs 8–13).