11 · Refactor toward insight

When you finish this lesson you should be able to:

Start a modeling improvement from a real pain, not from boredom with the folders
Use a small exploration group, then bring the language back to the whole team
Time refactors to follow insight (and incidents), not to fill idle weeks
Treat crisis as a chance to name the implicit rule while everyone still cares

This is a process chapter

You now have building blocks, implicit→explicit, and supple design. None of it happens as a one-person aesthetic pass. Evans’s chapter 13 is about how a team gets there.

Initiation

Refactor toward insight starts when:

a scenario is painful to walk
experts and developers keep talking past each other
a new feature has nowhere to sit (lesson 07’s “allocation checking” moment)

It does not start because someone wants to rename utils on a Friday. Drive-by renaming without experts forks the language (lesson 02).

Exploration teams

A few people (developer + expert, sometimes two developers) take a spike: try a deeper model on a vertical slice. They are allowed to be wrong. They come back with names and a demo, not a 20-page design.

If the exploration never reintegrates, you have a skunkworks dialect. Continuous integration inside the bounded context (lesson 12) still applies.

Prior art

Look at analysis patterns (lesson 10), the domain’s books, last year’s incident write-ups. Do not explore in a cultural vacuum. Also do not import a pattern the experts do not speak.

A design for developers

The target is a model developers like to use (supple) and experts recognize. If only one group is happy, you are not done. Hands-on modelers (lesson 03) are the bridge.

Timing

Too early: you do not know the contours; you will invent a framework.
Too late: the implicit model is in 400 conditionals; every change is a campaign.
Good: after a walk failed, after a breakthrough, after an incident named a rule.

Little refactors continuously; model refactors when you have a hypothesis and an expert.

Crisis as opportunity

Production is where implicit rules surface: “we never send two receipts.” Capture it that week as a concept (Delivery identity, Specification). Waiting three sprints loses the energy and the witnesses.

What strong engineers actually schedule

One modeling hour with an expert on a painful scenario.
A spike bounded to a day.
A rename + tests in the core module.
A demo that uses the new sentence in the ubiquitous language.

If your “DDD adoption” is only a shared kernel of base classes, you skipped this chapter.

Drill (15 minutes)

Name the last incident or the last feature that had “nowhere to sit.”
Write the implicit rule in expert speech.
Who would be on a two-person exploration? (roles, not a crowd)
What is the Friday artifact (a type, a test, a deleted flag)?
What you will not do (rewrite the platform, add a rules engine, rename everything).