Feature-Sliced Design
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").
The idea: split the project by meaning (business functions), not 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 a change in 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:
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, hooksRoles 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
shared → entities → features → pages → processes → appLower layers 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:
features/
add-to-cart/
ui/
AddToCartButton.tsx
model/
store.ts
selectors.ts
lib/
formatPrice.ts
index.tsA 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
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.tsxAdvantages 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:
components/
hooks/
utils/
pages/FSD offers:
shared/
entities/
features/
pages/Now, when you add a new capability, instead of thinking:
"Is this a component or a hook?"
you 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 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."
Short Answer
Interview readyA concise answer to help you respond confidently on this topic during an interview.