Feature Sliced Design: The Smart Way to Scale Fast

Feature Sliced Design is a way to structure frontend applications. It gives you rules for how to split your code into layers, business domains, and technical parts so the structure stays clear as the app grows.

Instead of only using folders like “components”, “hooks”, and “utils”, you use a feature-oriented frontend structure. You organize code into pages, features, entities, and shared parts, and each of these has a fixed place in the project tree. When you open the project, you see business concepts first and the technical details after that.

You can use the Feature Sliced Design approach with React, Next.js, TypeScript, or other stacks. It works well for modular and layered frontend architecture and is designed for modern component-based UIs and large-scale frontend applications.

Why Feature Sliced Design Was Created

Frontend systems are much more complex than before. A 2025 survey found that 86% of developers feel embarrassed about their current tech stack, and 58% of senior developers have thought about quitting because of legacy systems and technical debt. This shows how painful old and messy code can be in real projects.

React is still one of the most widely used web frameworks. The 2024 Stack Overflow Developer Survey says about 41.6% of professional developers use React in their daily work. So many teams are looking for frontend architecture best practices that fit well with React and similar tools.

Classic folder-by-type structures do not scale well. A huge “components” folder with hundreds of files turns into a monolithic frontend, with many hidden connections between parts of the code. Even a simple folder-by-feature layout can become messy if there are no clear rules about what should go where.

Feature Sliced Design builds on the folder-by-feature idea and adds clear layers, boundaries between domains, and rules for separating business logic in the frontend. It takes ideas from Domain Driven Design (DDD) and Clean Architecture and applies them to frontend code structure, so that business concepts shape how the project is organized.

Core Concepts: Layers, Slices, Segments

The main ideas in Feature Sliced Design are layers, slices, and segments. Together, they give your project a clear and consistent structure.

Layers In Feature Sliced Design

Layers in Feature Sliced Design are the highest level of the project structure. Each layer has a clear job and a fixed place. From top to bottom, the usual layers are:

• App layer (FSD): entry points, routing, global styles, and root providers. This is everything the app needs to start.
• Processes layer (FSD): flows that go across several pages, such as multi-step onboarding. This layer is mostly outdated now, but you may still see it.
• Pages layer (FSD): page modules, each linked to a route or a large part of a route.
• Widgets layer (FSD): self-contained UI blocks that combine features and entities, for example a dashboard panel.
• Features layer (FSD): user actions that create business value, such as “add to cart”, “reset password”, or “rate product”.
• Entities layer (FSD): core business objects, such as user, product, order, or invoice.
• Shared layer (FSD): reusable parts that are not tied to a single business domain, like design system components, common utilities, and API client wrappers.

This layered structure helps keep a large frontend project clear, and it works well with React and common JavaScript patterns.

Slices And Vertical Domains

Inside most layers, the next level in Feature Sliced Design is the slice. A slice is a business area such as user, product, cart, or article. Everything in that layer that belongs to that area is grouped inside its slice.

A slice is basically a small domain. You can think of it as vertical slicing of the frontend. Instead of grouping code by UI type, you group it by business meaning. This creates natural bounded contexts in the frontend and clear feature borders.

For example, in the entities layer, you might have slices like “user”, “product”, and “comment”. In the features layer, you might have slices like auth/login, “cart/add-item”, and “profile/edit”. This structure gives you a simple and practical way to break a large frontend into modules.

Segments Inside A Slice

Inside each slice, Feature Sliced Design splits the code again into smaller parts called segments. Segments are grouped by what the code does. The common segment names are “ui”, “model”, “api”, “lib”, and “config” or “consts”.

The “ui” segment holds React components and simple helpers for layout and display. The “model” segment holds state, business logic, and the rules that connect the UI to data sources. The “api” segment contains network calls and functions that prepare data from the backend. The “lib” segment keeps helper functions that are used only inside that slice. The “config” or “consts” segment stores configuration values and constants.

This structure keeps responsibilities separate. UI code does not need to know all the details inside the model, and the model can change without breaking everything that uses it. It also makes it easier to build reusable modules inside each domain.

Architecture Layers Explained In Practice

Dependency Rules Between Layers

In FSD architecture frontend, an important rule is how layers are allowed to talk to each other. The dependency rules FSD are simple: a layer can only import code from layers below it, not from its own layer and not from any layer above it.

How Layers Import Each Other in Practice

In everyday use, this rule works like this:

• A “pages” module can import “widgets”, “features”, “entities, and “shared”.
• A “features” module can import “entities” and “shared”, but not other features.
• An “entities” module can import only from “shared”.
• The “shared” layer is at the bottom and does not import anything from the layers above it.

Why These Import Rules Help

These import rules in Feature Sliced Design help keep your code easier to work with. They prevent circular dependencies, where files import each other in a loop, and tight coupling, where parts of the app are stuck too closely together. They also follow the dependency inversion principle in the frontend, so high level parts of the app depend on small, stable modules, not the other way around.

Code Ownership Across Layers and Slices

With these rules, layers and slices make code ownership frontend clear. If a team is responsible for a domain like “billing” or “catalog”, they can go straight to the slices for that domain in each layer instead of guessing where the logic is.

Public API Pattern And Dependency Rules

Each slice normally has one main entry file, usually called “index.ts”. This file defines the public API pattern frontend for that slice. Other parts of the app should only import from “index.ts”. Helper code stays inside model, api, or lib and should not be imported from other slices.

This setup helps in three ways:

1. It keeps features separate, because the rest of the app uses only the public API, not the internal details.
2. It also makes changes safer, because you mostly update code inside the slice and its “index.ts”.
3. It also supports business logic separation frontend, because the link between the UI and the domain logic is small and clear.

Together with the layer rules, this public API style gives you a clean feature sliced design pattern. Code goes from top to bottom through a few well known entry files, which helps the team grow and maintain the project.

Benefits Of Feature Sliced Design For Scalable Frontends

Teams use scalable frontend architecture Feature Sliced Design because it fixes real problems in daily work, especially when the app and the team grow.

The main benefits are:

• It makes the frontend code easier to maintain. The folder structure follows business terms, so developers can find code faster and new team members understand the project more quickly.
• It gives a clear way to split the app into slices. Each slice is a small domain with its own UI, model, and API, so related code lives in one place instead of being spread across many folders.
• It keeps features separate by using strict layers and public APIs. This reduces hidden connections and makes refactoring safer, because changes are mostly inside one slice.
• It helps team productivity in frontend architecture. Different teams can work on different slices at the same time, with fewer merge conflicts and less time spent coordinating changes.
• It fits well with scalable React architecture and enterprise frontend architecture, because Feature Sliced Design is about structure, not about one specific library or framework.

Feature Sliced Design Compared To Other Frontend Architectures

Most teams already use some kind of frontend architecture pattern. Comparing Feature Sliced Design (FSD) with these patterns makes it easier to see when FSD might be a better choice.

Feature Sliced Design vs Folder Structures By Type Or Feature

In a folder-by-type structure, you put files together by what they are: one folder for “components”, one for “hooks”, one for “services”, one for “utils”, and so on. This feels easy at the start, but as the app grows, code from many different business areas gets mixed in the same places.

The whole project starts to feel like one big block, and it becomes hard to see which files belong to which feature or business area. A folder-by-feature structure is already better, because the UI, hooks, and API for one feature live in the same folder. But even then, you often still have no clear layers, no obvious place for shared entities, and no strict rules for how parts depend on each other.

Feature Sliced Design is domain-first and adds those missing rules. It still groups code by feature, but it also adds layers (app, pages, widgets, features, entities, shared), segments inside each slice (“ui”, “model”, “api”, and so on), and strict import rules. Because of this, features are not only grouped, they are also clearly separated, shared code has a well-defined place, and the way parts of the app depend on each other stays controlled and predictable.

Feature Sliced Design vs MVC And Clean Architecture

In MVC, you split code into three parts: Model, View, and Controller. This works well on the backend. But in a React app, if you follow MVC directly, some components start doing everything at once: routing, state, side effects, and rendering. They become big and hard to understand. Clean Architecture adds more layers and tries to keep business rules separate from technical details. The idea is good, but it is quite abstract. It does not clearly tell you how to arrange folders and files in a real React or TypeScript project.

Feature Sliced Design keeps the same goal but makes it practical for the frontend. It groups code by pages and business areas (domains). Inside each slice, the model part holds state and business logic, and the “ui” part shows the interface. Features and entities act like the application and domain layers, while shared and app are closer to infrastructure and presentation. So you get the benefits of Clean Architecture, but with a clear folder structure and import rules that are easier to use in real projects.

Feature Sliced Design vs Atomic Design

Atomic Design is about how you build and combine UI components. It groups them into atoms, molecules, organisms, templates, and pages. Its main goal is to keep the design consistent and give the interface a clear visual structure. It does not deal with business domains or where to put business logic in the codebase.

Feature Sliced Design focuses on the domain and the overall architecture, not on visual levels of the UI. It cares about where business logic lives, how features are split by domain, and how dependencies move between layers. You can use both together: Atomic Design can organize components inside “shared/ui”, while Feature Sliced Design decides how those UI parts are used across pages, widgets, features, and entities. In this way, the design system and the domain architecture work together.

Feature Sliced Design With Micro Frontends

Micro frontends break a large product into several smaller frontend apps. Each small app can be built and deployed on its own. This helps when different teams own different parts of the product or need their own release schedules. But it also adds extra complexity and is not always a good choice for small or simple products.

Feature Sliced Design does not decide how many apps you have. It defines how code is organized inside each app. You can have one app or many micro frontends, and still use FSD with layers, slices, and segments inside each one. In practice, teams often use micro frontends to split the product into separate apps, and then use FSD inside each micro app as the feature based structure. This keeps every micro frontend clean, modular, and easier to maintain as it grows.

How To Implement Feature Sliced Design Step By Step

Step 1. Stabilize App and Shared Layers

Create an “app” folder for entry points, routing, and global providers. Create a “shared” folder for your UI kit, API client, and common helper functions. This alone already makes your frontend structure clearer and easier to work with.

Step 2. Start Slicing Pages and Widgets

Move existing screens into the “pages” layer. Take large repeated blocks, like dashboards or toolbars, and move them into the “widgets” layer. At this stage, you are shaping the Feature Sliced Design structure without changing much of the business logic.

Step 3. Extract Entities and Features

Find repeated domain objects, such as user, product, case, or invoice, and move their logic into the “entities” layer. Then find repeated user actions and move them into the “features” layer. Here, Feature Sliced Design naming conventions are important: use clear domain names, not generic or vague names.

Step 4. Add Segments As You Go

Inside each slice, divide files into “ui”, “model”, “api”, and maybe “lib”. Do not create all segments from the start. Begin with “ui” and “model”, and move network calls into “api” when it makes sense. Over time, this creates a Feature Sliced Design folder structure in React that matches how data and behavior actually flow.

Step 5. Enforce Dependency and Public API Rules

Create “index.ts” files as entry points for each slice and update imports to go through these files. Make sure imports always go from higher layers to lower layers. This applies the Feature Sliced Design import rules and makes your frontend easier to maintain.

Step 6. Migrate Legacy Modules Slowly

Migrate to Feature Sliced Design one feature at a time. Keep old code in a “legacy” folder while new or refactored parts follow FSD rules. Over time, more of the app moves into the new, cleaner structure.

Common Mistakes, Limitations, And When Not To Use It

Feature Sliced Design is useful, but it is not always the best choice.

One problem is using full FSD in very small apps. If you add all the layers, slices, and segments to a tiny project, you create a lot of extra folders and files without getting much benefit.

Another problem is splitting things too much. If every slice has many folders but only a few files, the project becomes harder to read and harder to move around in. It is better to start with a simple structure and add more folders only when you really need them.

FSD also takes time to learn. Developers who are used to simple flat folders may feel confused at first. A short document in the project and a quick walkthrough for the team can help a lot.

It is also important to know when you do not need FSD. For a simple landing page, a one-off internal tool, or an app with almost no shared logic, normal basic JavaScript structure is enough. Feature Sliced Design works best for big, long-running projects that will grow over time.

Best Practices And Team Workflow Tips

To get the most from Feature Sliced Design, treat FSD as a shared team rule, not just a folder layout.

Keep layer and slice names consistent and clear. Use the same words that product and domain experts use, so the code matches the real business domains (domain segmentation), not personal developer labels.

Keep each slice’s public API small. Export only what other slices really need.  This improves encapsulation (hiding internal details) and makes future code changes safer.

Try to match the structure with code ownership, so each team owns certain slices across the layers and is responsible for changing them. Architecture reviews should focus on architectural decision frontend topics, such as new layers, shared services, or shared libraries.

Remember that FSD is only one frontend architecture pattern. It can work together with Clean Architecture, Atomic Design, Domain-Driven Design, and micro-frontends, as long as you use each idea at the right level in your system.

Final Thoughts

Feature Sliced Design architecture is not a magic fix. You still need good engineering and discipline. What it gives you is a tested way to organize your frontend so the code is easier to maintain in modern React and Next.js projects. If you use layers, slices, and segments carefully, they give you a clear picture of how your frontend is structured.

FAQs