Suggest an edit

Improve this article

Refine the answer for “Feature-Sliced Design”. 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 Feature-Sliced Design (FSD) is

**Feature-Sliced Design (FSD)** is an architectural approach to organizing a frontend project,
where the code structure is built **around functionality (features)**,
rather than around technical layers (for example, "components", "utils", "pages").

> Idea: split the project **by meaning (business functions)**, rather than simply by file types.

## The main goal of FSD

> Make the project **scalable and understandable**:
> so that as the code grows you always know where to put a new module,
> and so that changing one feature doesn't break the others.

## Main levels (Layers)

FSD splits the project into **layers**, each with its own area of responsibility.
A typical structure looks like this:

```javascript
src/
  app/        → the root application (initialization, providers, routing)
  processes/  → cross-cutting business processes (for example: authentication, checkout)
  pages/      → pages (profile page, cart page, etc.)
  features/   → individual features (login, filtering, like, comments)
  entities/   → business entities (User, Product, Order, Post)
  shared/     → reusable utilities, UI, helpers, API, hooks
```

## Roles of the layers

| Layer | What it does | Example |
|---|---|---|
| **shared/** | Common, reusable parts | UI library, utils, hooks |
| **entities/** | Domain models | User, Product, Post |
| **features/** | Specific user actions | Liking a post, adding to cart |
| **pages/** | Assembles features and entities into a specific page | ProductPage, ProfilePage |
| **processes/** | Cross-cutting processes between pages | Authorization, checkout |
| **app/** | Entry point, router, global providers | App.tsx, Providers, ErrorBoundary |

## The "bottom-up" principle

```javascript
shared → entities → features → pages → processes → app
```

Lower levels **don't know** about higher ones.
For example:

- `shared` must not import anything from `features`;
- `features` can use `entities` and `shared`, but not the other way around.

This preserves the **directionality of dependencies** and the **cleanliness of the architecture**.

## Structure inside a feature

Each feature (or entity) is an **isolated module**
that contains everything it needs:

```javascript
features/
  add-to-cart/
    ui/
      AddToCartButton.tsx
    model/
      store.ts
      selectors.ts
    lib/
      formatPrice.ts
    index.ts
```

> A feature has **its own UI components**, **its own logic**, **its own types and store**.
> This makes it **independent and portable**.

## Example with React / Next.js

```javascript
src/
  shared/
    ui/
      Button.tsx
      Input.tsx
    lib/
      formatDate.ts
  entities/
    user/
      model/
        types.ts
        store.ts
      ui/
        UserAvatar.tsx
  features/
    login/
      ui/LoginForm.tsx
      model/store.ts
  pages/
    login/
      index.tsx
      ui/LoginPage.tsx
  app/
    providers/
      RouterProvider.tsx
      StoreProvider.tsx
    index.tsx
```

## Advantages of Feature-Sliced Design

| Advantage | Description |
|---|---|
| **Modularity** | Each block is isolated: easy to change or remove |
| **Scalability** | New features can be added without chaos |
| **Transparency** | Easy to understand where the business logic lives |
| **Dependency control** | Minimal "spaghetti imports" |
| **Compatible with Atomic Design** | `shared/ui` can store atoms, molecules, and organisms |
| **Integrates with any stack** | Next.js, React, Redux, Zustand, RTK Query, etc. |

## A real-world example

Instead of a chaotic structure like:

```javascript
components/
hooks/
utils/
pages/
```

FSD offers:

```javascript
shared/
entities/
features/
pages/
```

Now, when you add a new capability, you don't think:

> "Is this a component or a hook?"

but think:

> "Is this a **feature** (an action) or an **entity** (an object)?"

## Modern practices in FSD

- Use **import boundaries** (for example, `eslint-plugin-boundaries`)
- Export only `index.ts` to the outside (public API)
- Decompose the UI following Atomic Design inside `shared/ui`
- Separate logic and presentation (`model`, `ui`, `lib`, `api`)

## Summary

| What | Description |
|---|---|
| Idea | Structure the frontend by **business functions**, not by file types |
| Main layers | shared → entities → features → pages → processes → app |
| Goal | Scalability, modularity, clarity |
| Basic unit | Feature: an isolated module |
| Best suited for | Large React / Next.js projects |

---

> **The FSD formula:**
> "Group code by meaning, not by technology.
> Let each feature live in its own space and know nothing about the others."

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

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.