Rule 9 of 38 · Chapter II — Design for Change
Isolate what changes from what stays
Why this rule exists
In most systems a small part changes often while the rest stays put. When the volatile and the stable are tangled together, every change to the fast-moving part risks the slow-moving core, and testing means dragging in things that had no reason to move. Separating the two lets each evolve at its own pace with a clear seam between them.
In practice
Identify what varies: pricing rules, external formats, UI copy, vendor APIs. Put each behind its own boundary and keep the stable core ignorant of the details. When a new variation arrives, it should touch only its own region. If a routine change forces edits across unrelated modules, your seam is in the wrong place.
When it doesn't apply
Do not split things apart before you know what actually varies; premature seams add indirection for changes that never come. Wait until you have seen a dimension of change at least once, then isolate it.