Layered, N-tier, client-server, and broker styles
Structural styles arrange responsibilities and allowed dependencies. They are starting shapes, not complete solutions. Logical layers and physical tiers are different decisions.
Core ideas and patterns
| Idea | What it solves | Cost, limit, or warning |
|---|---|---|
| Layered | Separates presentation, application, domain, and infrastructure concerns | Strict traversal can add pass-through code |
| N-tier | Deploys processing into separate physical/network tiers | Network hops and partial failure appear |
| Client-server | Centralizes service behind client requests | Server capacity and availability become critical |
| Broker | Mediates discovery and interaction between distributed components | The broker adds operational and semantic dependency |
| Three-tier | Separates UI, application, and data tiers | Does not guarantee domain modularity |
| Closed layers | Only allow dependency on the next lower layer | Can force irrelevant indirection |
| Relaxed layers | Permit intentional layer skipping | Without rules, layering erodes |
How to apply it
Define each layer’s responsibility and dependency rule. Keep business policy independent of delivery and storage mechanisms where changeability matters. Decide separately whether a logical layer needs a process or network tier. Avoid mapping every folder to a deployable unit.
Evidence, not opinion
Use build-time dependency rules, API tests, latency budgets per hop, network-policy checks, and deployment topology validation. Test a whole use case to expose layers that only forward data.
Small example
A web application can have four logical layers in one process and two physical tiers. That is not the same as four network services.
Feynman check
Explain the design to a new engineer without using the pattern names. State the problem, the forces that conflict, the chosen boundary or mechanism, what can fail, and the evidence that would prove the choice still works.