Architecture improvement

Find the design pressure

Inspect the relevant flow, module boundaries, dependencies, and tests. Check applicable architecture guidance and existing decisions before proposing a direction.
Identify concrete friction: a rule maintained in several places, changes spreading across unrelated modules, unclear ownership, dependency cycles, or a boundary that makes behavior difficult to test.
Separate observed problems from anticipated needs. Base anticipated needs on known requirements or change patterns; name assumptions that affect the choice.

Compare the current structure with the smallest structural improvement that addresses the friction. Consider ownership, dependency direction, clarity, testability, and migration cost. Explain the determining trade-off briefly.
Introduce an abstraction when it gives an invariant one owner, expresses a domain concept, separates independently changing concerns, or isolates an external dependency. Duplication is evidence, not a prerequisite.
Group behavior that changes for the same reason. Keep distinct concepts separate even when their implementations look alike; avoid generic helpers with flags for unrelated cases.
Prefer explicit boundaries and narrow contracts. Add layers, interfaces, or patterns only when they solve the identified problem; evaluate them against the project's stack and scale.
Judge simplicity by the code a maintainer must understand and change, not by diff size. A larger refactor can be simpler overall when it removes repeated work or hidden coupling.