Feature-Sliced Design (FSD) in Frontend Development

Feature-Sliced Design (FSD) is a frontend architecture pattern that helps organize code by features and business domains, not by technical layers (like components, pages, or services). It is especially useful in large-scale React applications.

1. Why Use Feature-Sliced Design?

• Scalability: Organizes large codebases into manageable, logical units.
• Isolation: Each feature is decoupled, making testing and development more predictable.
• Team Collaboration: Enables teams to work in parallel with fewer merge conflicts.
• Encapsulation: Features control their own state, UI, and logic.

2. FSD Structure Overview

src/
├── app/            # App configuration and initialization
├── entities/       # Reusable domain models (e.g., User, Article)
├── features/       # Functional features (e.g., Login, AddToCart)
├── shared/         # Shared components, utilities, constants, styles
├── pages/          # Route-based pages composed of features/entities
└── widgets/        # UI blocks made of entities/features (e.g., Header)

3. Core Layers in FSD

1. app/

• Root of the application.
• Includes routing, theme, i18n, and app-level providers.

2. entities/

• Business domain models that are reusable and stable (e.g., User, Product).
• Includes UI, logic, API, and state.

3. features/

• User-facing actions or business logic (e.g., user-login, add-to-favorites).
• Built using entities.

4. widgets/

• UI compositions of entities and features, used in pages or layouts (e.g., Header, Sidebar).

5. pages/

• Actual application pages.
• Composed of widgets, features, and entities.

6. shared/

• General-purpose code used across all layers (e.g., UI components, helpers, types).

4. Benefits of FSD

• Enforces modular thinking.
• Encourages domain-driven design.
• Promotes better separation of concerns.
• Supports team autonomy and feature-based delivery.

Summary

Feature-Sliced Design is a scalable architecture for frontend apps, especially React. By organizing code around business features and roles, it leads to better maintainability, reusability, and team efficiency.

Interview angle

• “Layer-based or feature-based structure?” - feature-based scales better past a certain size: a change lives in one directory instead of touching models/, services/ and api/ separately. Layer-based is fine for small services and becomes a navigation cost as the codebase grows.
• “What actually makes it work?” - enforced boundaries. Without a rule that features may not import each other’s internals, feature folders become layer folders with extra steps. Enforce with import-linter or an architecture test in CI.
• “How do features share code?” - a shared or common layer for genuinely cross-cutting concerns, with the dependency direction one-way: features may import shared, shared may never import a feature. A cycle there is the first sign the boundary has eroded.
• “How does this relate to DDD?” - a feature slice often corresponds to a bounded context. If it does, the structure reinforces the domain boundary rather than fighting it.