Suggest an edit

Improve this article

Refine the answer for “What is "Layered Architecture" in frontend?”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

## What Layered Architecture is

> **Layered Architecture** is the principle of splitting an application into **layers**,
> where each layer has **its own area of responsibility** and **limited dependencies**.

In other words:

> Each layer is responsible **for one aspect of the system**,
> and knows **only about the layers below it**, never above.

---

## Why layers are needed

As an application grows, logic, data, and UI start to mix together.
Layers let you structure this:

- each layer solves **its own task**,
- interaction between layers is clearly defined,
- and the code becomes **predictable and scalable**.

---

## Typical levels (frontend version)

| Layer | Area of responsibility | Example |
|---|---|---|
| **UI / Presentation Layer** | Displays data to the user | React components, forms, buttons |
| **State / Application Layer** | Manages application state and business rules | Redux / Zustand / Hooks / Context |
| **Domain Layer** | Holds business logic and domain models | functions like `calculateDiscount()`, `UserEntity` |
| **Data / Infrastructure Layer** | Works with external data sources | REST, GraphQL, API clients, LocalStorage |

---

## Example (React + API)

### Without layers (everything in one component)

```javascript
function ProductList() {
  const [products, setProducts] = useState([]);

useEffect(() => {
    fetch("/api/products")
      .then(res => res.json())
      .then(setProducts);
  }, []);

return (
    <div>
      {products.map(p => (
        <div key={p.id}>{p.name} - {p.price}$</div>
      ))}
    </div>
  );
}
```

> Here the component simultaneously:
>
> - makes the request (data layer),
> - manages state (application layer),
> - renders the UI (presentation layer).
>
> → An architectural "mess".

---

### With separation into layers

```javascript
// data/productsApi.js
export async function getProducts() {
  const res = await fetch("/api/products");
  return res.json();
}

// domain/productService.js
export function calculateDiscount(product) {
  return product.price * 0.9;
}

// model/useProducts.js (application/state layer)
import { useEffect, useState } from "react";
import { getProducts } from "../data/productsApi";
import { calculateDiscount } from "../domain/productService";

export function useProducts() {
  const [products, setProducts] = useState([]);

useEffect(() => {
    getProducts().then(res => {
      setProducts(res.map(p => ({
        ...p,
        discounted: calculateDiscount(p)
      })));
    });
  }, []);

return products;
}

// ui/ProductList.jsx (presentation layer)
import { useProducts } from "../model/useProducts";

export function ProductList() {
  const products = useProducts();
  return (
    <div>
      {products.map(p => (
        <div key={p.id}>
          {p.name} - {p.discounted}$
        </div>
      ))}
    </div>
  );
}
```

> Now each layer is isolated:
>
> - `data/` - handles requests
> - `domain/` - business logic
> - `model/` - state
> - `ui/` - rendering

---

## Layer dependency rules

```javascript
UI → Model → Domain → Data
```

- **UI** knows about **Model**, but not about **Domain** directly
- **Model** can reach into **Domain** and **Data**
- **Domain** is independent (knows nothing about UI or the API)
- **Data** is the bottom layer, serving everyone

> The direction of dependencies always points "downward".

---

## Layered Architecture in Feature-Sliced Design

In FSD (Feature-Sliced Design), this principle is formalized as **project layers**:

```javascript
shared/      ← (infrastructure and shared modules)
entities/    ← (domain models)
features/    ← (application features)
pages/       ← (assembling features into pages)
processes/   ← (cross-cutting scenarios)
app/         ← (application initialization)
```

> Each layer depends **only on the layers below it** -
> for example, `features` can use `entities`, but not the other way around.

---

## Advantages of Layered Architecture

| Advantage | Description |
|---|---|
| **Separation of responsibilities** | Each layer solves one task |
| **Isolation of changes** | You can change a layer without breaking others |
| **A clear structure** | The project is easy to read and scale |
| **Testability** | Layers are tested independently |
| **Reusability** | Business logic can be extracted into other projects |
| **Compatibility with DDD/FSD** | Integrates easily with modern architectural approaches |

---

## Layered vs Feature-Based Architecture

| Approach | Splits by... | Example |
|---|---|---|
| **Layered Architecture** | Roles (UI, Logic, Data) | `ui/`, `domain/`, `data/` |
| **Feature-Based Architecture** | Functionality (auth, cart) | `features/auth/`, `features/cart/` |

> The best option is **to combine both**:
> inside each **feature** you can also keep **layers** (`ui/`, `model/`, `domain/`, `api/`).

---

## Summary

| What | Description |
|---|---|
| Idea | Split the application into logical levels with clear dependencies |
| Main layers | UI / Application / Domain / Data |
| Direction of dependencies | Top to bottom only |
| Goal | Structure, readability, scalability |
| In React | Often implemented inside features (through FSD or Clean Architecture) |

---

> **Main idea:**
> Layered Architecture is the "architectural skeleton" of an application:
> each layer knows its place and does not interfere with others' business.
>
> This makes the code **understandable, testable, and resilient to project growth**.

Markdown · drag & drop images · ⌘B / ⌘I shortcuts794 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.