Different Layer, Different Abstraction
- Categories
- Design
- Sources
- A Philosophy of Software Design
In a well-structured system, each layer presents a different abstraction from the layers above and below it. When adjacent layers have similar abstractions, that is a sign the boundary between them is not pulling its weight.
Why it Matters
A layer earns its place by transforming the abstraction, not by relaying it. Layers that look like their neighbors add interfaces and indirection without hiding anything, which is complexity with no offsetting benefit.
Signals
- Pass-through methods that do little but forward arguments to another method with the same signature.
- Decorators or wrappers that mostly duplicate the interface they wrap.
- A variable or object threaded through many methods that only pass it along (a pass-through variable).
Benefits
Removing redundant layers shortens call chains, shrinks the number of interfaces, and makes each remaining boundary meaningful. Fewer layers, each doing real abstraction work.
Risks
The fix is not always "delete the layer." Sometimes the right move is to redistribute responsibility so the layer does transform the abstraction. Collapsing layers blindly can merge concerns that should stay separate.
Tensions
Conflicts with reflexive layering and with patterns applied for their own sake (a wrapper "because we always add one"). Add a layer only when it changes the abstraction.
Examples
A method that simply calls a lower method with identical parameters is a pass-through and a red flag. A networking layer that turns byte streams into typed messages is a genuine change of abstraction and earns its boundary.