Book 09 · Software ArchitecturePage 25 of 48

Layered Architecture

In Turkish: Katmanlı Mimari

Updated September 30, 20263 min read

In short

Layered architecture splits an application into horizontal layers, such as presentation, business logic, and data access, each calling only the layer below it.

What is layered architecture?

Layered architecture is one of the oldest and most common ways to structure an application. The code is divided into horizontal layers, each with one kind of responsibility, stacked on top of each other. A typical web application has a presentation layer that handles HTTP requests or the user interface, a business logic layer, often called the service layer, that applies the rules of the domain, and a data access layer that reads and writes the database.

The key rule is that dependencies point downward: a layer may call the layer directly beneath it but should never call upward. In a strict, or closed, layered design every request passes through each layer in turn, while a relaxed, or open, design lets some calls skip a layer. Because each layer hides its details behind a clear interface, you can change how data is stored or how pages are rendered without rewriting the business rules, and developers always know where a given kind of code belongs.

A restaurant is a good analogy: waiters take orders at the front, cooks prepare the food in the kitchen, and the storeroom supplies ingredients. The waiter never goes to the storeroom directly, and the storeroom never talks to customers. Layered architecture is the default shape of many enterprise and web applications and of many framework starter templates, and it is a sensible starting point for a monolith.

Layered architecture is often compared with clean and hexagonal architecture. In a classic layered design the business logic depends on the data access layer, so database details can leak upward, while clean and hexagonal architecture invert that dependency so the core defines interfaces and the database code plugs into them. It is also different from MVC, which organizes the presentation layer itself, and a layer, which is a logical grouping of code, is not the same as a tier, which is a separate physical machine or process.

Key takeaways

Code is split into horizontal layers such as presentation, business logic, and data access.
Each layer depends only on the layer below it.
Layers make responsibilities clear and let parts change independently.
In classic layering the business logic depends on data access; clean and hexagonal architecture reverse that.
Layers are logical groupings of code; tiers are physical deployments.

Example

Three layers of a small order featuretypescript

// Data access layer: the only code that talks to the database
const orderRepository = { insert: (order: object) => db.insert("orders", order) };

// Business logic layer: applies the rules, then calls the layer below
const orderService = {
  async placeOrder(items: string[]) {
    if (items.length === 0) throw new Error("An order needs at least one item");
    return orderRepository.insert({ items, status: "placed" });
  },
};

// Presentation layer: handles HTTP and calls the business layer
app.post("/orders", async (req, res) => {
  res.status(201).json(await orderService.placeOrder(req.body.items));
});

Readers ask

What is the difference between a layer and a tier?

A layer is a logical grouping of code inside an application, such as the business logic layer. A tier is a physical deployment unit, such as the browser, the application server, and the database server in a three-tier system, so several layers can run in a single tier.

What is the difference between layered and clean architecture?

Both separate responsibilities, but they point dependencies differently. In layered architecture the business logic depends on the data access layer, while in clean architecture the business core depends on nothing and the database code implements interfaces the core defines.

What is the architecture sinkhole anti-pattern?

It happens when most requests pass straight through the layers without any real logic, such as a service method that only calls a repository method. A little of this is normal, but if it is everywhere, the layers add ceremony without value.