Skip to content
Software Architecture Guide

Layered Architecture

Explanation

Section titled “Explanation”

A layered architecture divides a system into layers. Each layer has one specific responsibility. The key rule is about direction: a higher layer may use the services of a lower layer, but a lower layer may not use a higher one. Architects call this a unidirectional “allowed-to-use” relation.

Typical layers. A common split has three parts:

  • a presentation layer (what users see),
  • a domain layer, also called business logic (the rules of the business),
  • a data access layer (reading and writing data).

Dependencies run from top to bottom through this stack.

Why it helps. The domain logic sits in its own layer, so several presentations can share it. A web site and a mobile app, for example, can use the same logic without copying it. Layer boundaries also give natural seams for testing parts separately.

Early use. Dijkstra’s THE operating system imposed the rule that higher layers depend only on lower layers. This made the system easier to reason about. It also let the designers build and test it step by step.

Strict and relaxed layering. In strict layering, a request passes through each adjacent layer in turn. In relaxed layering, a layer may skip layers. Strict layering costs more latency and overhead. Relaxed layering adds couplings, which make changes harder.

Layers and tiers. Logical layers can be hosted on separate physical tiers. This improves scalability and resiliency. It also adds network latency.

Layers in Domain-Driven Design. In DDD (see Domain-Driven Design), each layer depends only on the layer below it. Isolating the domain layer from user interface and persistence code is central. Sometimes a lower layer must notify an upper one. Callbacks, observers or events can handle this. Use them with restraint.

N-tier. An n-tier style suits evolving requirements. It also suits moving existing on-premises applications at low cost. It is portable and easy for developers to learn.

Example

Section titled “Example”

An online shop has three layers. The presentation layer shows product pages on the web and in a mobile app. The domain layer calculates prices and discounts. The data access layer reads and writes orders. The web page asks the domain layer for a price. The domain layer never calls the web page directly. When the discount rules change, only the domain layer changes. Both apps benefit at once.

Trade-offs

Section titled “Trade-offs”
  • Strict vs. relaxed: strict layering has more latency and overhead. Relaxed layering has more couplings, so changes get harder.
  • Pass-through traffic: closed layers limit dependencies. They can cause needless network traffic when a layer only forwards requests.
  • Separate tiers: hosting layers on different tiers improves scalability and resiliency. It adds latency from extra network communication.
  • Upward calls: the “never upward” rule needs callbacks, observers or events when a lower layer must notify a higher one. Use them with restraint.

Layers where each one uses only the layer beneath it.

Diagram source 
flowchart TD
  A[Presentation layer] --> B[Domain layer]
  B --> C[Data access layer]
  C --> D[(Database)]

Checks

Section titled “Checks”
  • The document states that each layer has a defined responsibility and that dependencies run only from higher to lower layers.
  • The document says whether layering is strict or relaxed, and names the latency or coupling consequences.
  • Any upward communication from a lower layer is handled through callbacks, observers or events, and is documented.
  • The domain layer is isolated from user interface and persistence code.
  • If layers run on separate tiers, the document notes the added network latency.
Section titled “Related”

Sources

Section titled “Sources”