Rule 10 of 38 · Chapter II — Design for Change
Push decisions to the edges
Why this rule exists
Decisions like which database, which format, which vendor, are easiest to change when they live at the system's edges rather than woven through the core. Pushed inward, they contaminate business logic and become expensive to revisit. Kept at the boundary, they stay swappable and the core stays focused on the problem rather than the plumbing.
In practice
Keep policy and business rules in the center, free of I/O and framework details. Do configuration, serialization, and third-party calls at the outer layer and hand plain data inward. When you find a vendor SDK type deep in your domain logic, that is a decision that leaked; move it out to the edge behind a thin adapter.
When it doesn't apply
For small tools or short-lived code, edge-to-core layering is more structure than the problem warrants. And some decisions are so foundational and settled that threading them through directly costs less than the ceremony of isolating them.