Refactoring toward one copy
Software architecture · 2026-09-13
DRY at the level of meaning, the burden of proof on staying local, and why simplicity outranks every pattern.
Compare meaning, not spelling
A duplication scanner sees two identical files. It cannot see two different files that encode the same rule, and it cannot see a site that is missing a feature entirely, which scores perfectly on dryness. So the measurement is a signal, not a verdict: trace each hit to the rule it encodes, keep two rules apart when their meanings differ, and merge them when they only differ in spelling.
The burden is on staying
In a factory, a file needs a reason to remain local, not a reason to move. "Only one caller", "it is product code", "the artwork is this site's" are rejected. The one surviving reason: sharing it would force two genuinely different product rules to mean the same thing, and you must name both rules.
The test for every file: would site number five have to write this again? If yes, it belongs in the engine even when only one site uses it today.
Simplicity outranks the pattern
A seam every site fills with the same value is complexity. A layer that only forwards is complexity. A strategy with one strategy, a configurable engine for one rule, a checker for a checker: each is a finding. Inlining an indirection is as much a refactoring as extracting one, and "no pattern, plain functions" is often the correct answer.
Two designs that both meet the requirements are not equal. The simpler one is correct and the other is a defect. Simplicity never buys a defect, though: a race, a missing refund, a weakened gate is not simpler, it is broken.
same rule, two spellings ──► one source of truth two rules, one name ──► keep apart, name both a layer that only forwards ──► inline it