13 · Distill the core

When you finish this lesson you should be able to:

• Write a domain vision statement that names what is worth building
• Separate core, supporting, and generic subdomains
• Use the distillation ladder without jumping to “abstract core”
• Choose refactoring targets that move the core, not the email sender

Distillation as strategy

Maxwell’s equations analogy in Evans: a small set of statements can carry a whole field—if you have the right ones. A layered architecture isolates domain from technical logic, but a large domain is still a swamp. Distillation separates the mixture so the valuable part is usable.

A model is already a distillation of knowledge. Strategic distillation of the whole domain:

1. Helps people grasp how the system fits
2. Gives a core of manageable size to the ubiquitous language
3. Guides refactoring
4. Focuses work on highest value
5. Guides buy-vs-build, outsourcing, staffing

The by-products (generic subdomains, mechanisms) get cleaner too. The motive is extracting the core domain—what makes this software worth existing.

Core domain

Where the business is distinctive. Deep models and supple design belong here. If your strongest engineers are on Kubernetes and the leftover staff own “decisioning,” you inverted the bet.

Ask: if we outsourced this module, would we still be us? If yes, it is not core.

Generic subdomains

Identity login-as-usual, SMTP, invoice-as-usual, a CMS. Necessary. Not distinctive. Buy them, or give them a boring module and a tight interface. Do not interleave SmtpClient with Holdout.

Supporting subdomains sit in between: needed for the core, not generic enough to buy, not the reason you exist. Keep them clean; do not let them steal attention.

Escalation of distillations (mild → aggressive)

Use only as far as you need:

1. Domain vision statement — a page: purpose, core, what we are not.
2. Highlighted core — mark it in code and on the map so people stop casually adding here.
3. Cohesive mechanisms — pull out algorithms (rule engines, graph math) so the core reads as domain.
4. Segregated core — physical module boundary; dependencies cannot leak inward casually.
5. Abstract core — a true abstract language across parts. Rare. Easy to fake. Skip unless you have proof.

Deep models distill: the core often shrinks as insight improves. A core that grows every quarter is a smell: everything became “strategic.”

Choosing refactoring targets

Pick: in the core, unlocks several features, expert available, language already twitching. Do not polish generic email. Do not “clean architecture” a supporting CRUD app (Smart UI may be correct—lesson 04).

Example vision (consumer growth)

“We put the right next experience in front of someone who already trusted us, without double-notifying or breaking holdout. Billing is a supplier. Email is a mechanism. Password reset is generic.”

Then you know: a week on Assignment invariants beats a week on HTML templates.

If Holdout and SmtpClient share a class, distillation has not happened.

Drill (20 minutes)

1. Six-sentence vision. Circle core sentences.
2. Five modules: core / supporting / generic.
3. One type in the wrong bucket. Move it.
4. One core refactor target and the invariant you would make explicit.
5. One generic subdomain you will stop customizing.

Further reading

• Domain-Driven Design — Chapter 15, Distillation (core; generic subdomains; vision; highlighted / segregated / abstract core; refactoring targets)