A design has four layers. The service layer contains no logic - it forwards every call from the controller to the repository. What would you change?

What is being tested

Whether you can distinguish a structure that serves a purpose from one that satisfies a diagram.

The reasoning

Layering's value is not the layers; it is the enforced dependency direction — a change in storage cannot propagate upward into the domain. A layer that adds no behaviour contributes nothing to that property. It contributes only:

• An extra function call and an extra file per feature.
• Another place to look when debugging.
• Another set of types to map between, or the same types leaked through, which defeats the point anyway.
• A permanent maintenance obligation that will outlive everyone who remembers why it exists.

Remove it. If genuine domain logic appears later, reintroduce the layer then — that refactor is mechanical and cheap. Keeping an empty layer against a future that may never arrive is the same error as any premature abstraction: paying now for an option that may never be exercised.

Why "add logic to justify it" is the wrong instinct

It inverts cause and effect. Structure should follow from a requirement, not requirements be invented to justify structure. If it takes an argument to explain why a component exists, that is evidence about the component.

The wider failure this represents

Diagram-driven design. The reference model has a services layer, so a services layer is created. This is the same pathology as adopting a cloud vendor's full reference topology to run two containers, and it is remarkably persistent because omitting something feels riskier than including it — teams over-adopt out of fear of being asked why something is missing.

The antidote is to record the decision: "no separate service layer; controllers call repositories directly because there is no cross-repository orchestration today." Now the omission is deliberate and defensible rather than looking like an oversight.

Where a layered structure genuinely misleads

Two cases worth knowing:

Layers confused with tiers. Layers are logical, tiers are physical. Deploying each layer as its own process because they are drawn as separate rectangles converts local calls into network calls and gains nothing but failure modes.

Change that cuts across layers. If every feature touches all four layers, the layering is cutting across the axis of change rather than along it. Organise by feature or capability first, and layer inside each.