Skip to content
Software Architecture Guide

Layers Pattern

Explanation

Section titled “Explanation”

The Layers pattern is an architectural pattern (see Architectural Pattern). It divides a system into layers. Each layer has one specific responsibility. Layers also manage the dependencies between parts of the system.

The core rule. A higher layer may use the services of a lower layer. A lower layer may never use the services of a higher layer. This is a one-way “allowed-to-use” relation: there is no upward usage.

Strict and relaxed layering. Two styles exist:

  • In a closed (strict) layer architecture, a layer calls only the layer directly below it.
  • In an open (relaxed) layer architecture, a layer may call any layer below it. This is similar to what architects call bridging.

You can mix both styles in one system.

What you gain.

  • Developers can narrow their focus to one piece at a time.
  • Module boundaries create seams. You can substitute an implementation or test a piece at those seams.
  • Layered (N-tier) designs can be portable across cloud and on-premises environments, and between cloud platforms.
  • Limited dependencies keep change contained. See Coupling and Cohesion.

Organizing teams. Fowler calls organizing development teams by layer an antipattern. Team boundaries add friction to work that crosses layers.

Background. In object-oriented design, a layer is a group of classes that share the same link-time dependencies. Layers are often arranged as a hierarchy. The pattern is described in several well-known books. In the T.H.E. operating system, layers were built bottom-up. Layer 0 handled scheduling and context switching.

Example

Section titled “Example”

A web shop has three layers: presentation, business rules and data storage. The presentation layer calls the business rules. The business rules call data storage. Data storage never calls the business rules. In strict mode, presentation never touches data storage directly. In relaxed mode, it may.

Trade-offs

Section titled “Trade-offs”
  • Latency and overhead. Strict layering has more latency and overhead. A closed layer that only forwards requests can create unnecessary traffic.
  • More couplings. Relaxed layering adds couplings, which makes change harder.
  • Empty layers. A middle layer that only does basic create, read, update and delete operations adds latency and complexity without real value.
  • Team structure. Splitting teams along layers adds friction to cross-layer work.

Usage flows downward only. The dotted arrow shows relaxed layering.

Diagram source 
flowchart TD
  A[Upper layer] --> B[Middle layer]
  B --> C[Lower layer]
  A -.relaxed: bridging.-> C

Checks

Section titled “Checks”
  • Each layer has a stated responsibility, and the document says which layers may use which.
  • No lower layer uses a higher layer.
  • The document states whether layering is strict, relaxed or mixed.
  • Any layer that only forwards requests has been justified against its latency cost.
Section titled “Related”

Sources

Section titled “Sources”