Architecture Overview

“Feature Sliced” design has been gaining more and more popularity among the frontend community for its undeniable benefits. It has proven to be highly scalable and reliable, making it an excellent choice for large teams working on complex projects.

The huge advantage of that approach, which helps it stands out from any other frontend architecture, is its business orientation. This makes it suitable for almost any project and makes it easy to keep things well-organized as new features are added. Moreover, it can be adopted incrementally, which is incredible news as you can implement it in an already existing product. However, keep in mind that this methodology is designed to be used only for the frontend.

In “Feature Sliced Design” a project consists of layers, each layer is made up of slices, and each slice is made up of segments. Before going deeper into the layers, slices, and segments, I suggest you take a glance at the global picture below.

Layers

Top-level folders of “Feature Sliced Design” are called “Layers” and are the first level of application partitioning. We have a strict number of possible layers and some of them are optional. Layers are standardized and at the current moment, there are seven of them:

• Shared layer. It contains various reusable, independent of business logic functionality. Perfect examples of that can be UI-kit, helpers, and loggers
• Entities layer. It contains business entities, which are specific to the project. For example User, Payments, Products, and so on
• Feature layer. It contains user stories. Code that brings business value to the user. For example ChangePassword, MakePayment, BuyProduct
• Widgets layer. It contains components that combine entities and features. For example UserSettings, PaymentsList, ProductsList
• Pages layer. It contains application pages. That is the compositional layer that is constructed from entities, features, and widgets
• Processes layer. It contains complex inter-page scenarios. For example authentication and captcha
• App layer. It contains application settings, styles, and providers. For example withAuth HOC

Each of the layers has its own zone of responsibility and as you can notice they are highly business oriented. Also, they have a stepped hierarchy, which you can see in the picture below. It is done in that way as it creates an understandable unidirectional data flow that plays a significant role in approach usability.

The lower the module is placed in the hierarchy, the more it is dangerous to refactor it. For example, if you change Modal the component in the shared layer that can hugely affect the rest of the application.

🌟 Don’t forget to subscribe to learn more important things about Frontend!

Slices

Now it’s time to talk about “Slices”. They are simply subfolders of a layer and are dependent on project specifics, team, and technology stack. Also, they are not coupled to some abstract things like layers, each slice represents a specific thing. You can understand them as modules, which have rules you should follow:

• Slices of the same layer cannot use each other directly
• Their composition should be placed on the upper layer relative to the current one
• In most cases, you should avoid nesting in slices, and use only structural grouping by folders

Here are examples of slices for each of the possible layers:

├── app/
|   # Application composition layer
|   # Only contains abstract initialization logic and static assets, and thus mustn't contain any Slices
|
├── processes/
|   # Slices implementing page-independent workflows or workflows involving multiple pages
|   ├── auth
|   ├── payment
|   ├── quick-tour
|
|
├── pages/
|   # Slices implementing complete application views
|   ├── feed
|   |
|   ├── profile
|   |   # Due to routing specifics, this layer can contain nested structures
|   |   ├── edit
|   |   └── stats
|   |
|   ├── sign-up
|
|
├── widgets/
|   # Slices implementing various combinations of abstract and / or business units from lower layers,
|   # to deliver isolated atomic User Interface fragments
|   ├── chat-window
|   ├── header
|   ├── feed
|
|
├── features/
|   # Sliced implementing user scenarios, which usually operate on business entities
|   ├── auth-by-phone
|   ├── create-post
|   ├── write-message
|
|
├── entities/
|   # Slices implementing business units in terms of which application business logic works
|   ├── account
|   ├── conversation
|   ├── post
|   ├── wallet
|
|
├── shared/
|   # This layer is a set of abstract Segments
|   # It means that it must not contain any business units or business-related logic

Segments

Each slice consists of smaller modules called “segments”. There are meant to help with separating code within a slice by its technical purpose. Here is a list of the most common segments, but you can be flexible and omit or add more.

• UI segment. It simply contains UI logic
• Model segment. It contains business logic, such as stores, actions, effects, and reducers
• Lib segment. It contains infrastructure logic, such as utils and helpers
• Config segment. It contains the configuration of the slice
• API segment. It contains the logic of API requests such as requests themselves or API instances.

Public API

Every “Slice” and “Segment” must have its own declaration of “Public API”. That is simply an index file that represents an access point to the module’s internals and defines how the outer world can interact with the module.

└── features/ # 
 ├── auth-form / # Internal structure of the feature
 | ├── ui/ #
 | ├── model/ #
 | ├── {…}/ #
 | ├── index.ts # Entrypoint with its public API 

As the “Public API” is the entry point for the module, here are some rules you should follow:

• Other parts of the application can use only those module entities that are presented in the public interface
• The internal part of the module outside the public interface is accessible only to the module itself

The well-declared public interface should be convenient for use by the rest of the application and be sustainable for changes inside the module, so you don’t have to change imports in plenty of places when something is modified.

Pros and Cons of the Architecture

Undoubtedly, “Feature Sliced Design” brings a ton of value to the table. It excels in almost any realm when compared to other approaches. The main pros are:

• Orientation to business and user needs
• Controlled reuse of logic
• Stability in face of changes and refactoring
• High scalability in terms of architecture and team
• Incremental adoption
• Independence of technological stack
• High standardization
• Perfect documentation and a big community

Cons:

• It adds more project knowledge from the start as you have to learn an approach to start creating value. But to be honest, it also hugely decreases project knowledge as the project broadens due to standardization
• Not suitable for MVP or short-living projects, as you increase development time and don’t get any significant benefits on short distances
• It requires special team culture and strict code review to follow all the architectural principles

Overall, “Feature Sliced Design” is a powerful approach that brings a ton of value to your project. By breaking down the application into small, modular components, we create low-coupled and highly cohesive code.

Tip: It’s worth mentioning that an open-source toolchain like Bit is an ideal tool to use in conjuction with the “Feature Sliced Design” approach. After identifying common components across your micro-frontends and isolating them, you can use Bit to manage, version, and share them across projects. This is an elegant and maintainable solution that will help both scalability and reusability, and enable better collaboration between your teams. Find out more here.

“FSD” Low Coupling and High Cohesion

Comparison with the “Simple Modular” Architecture

For reference, the “Simple Modular” architecture was previously discussed in this article.

It seems to me that for any middle/high complexity projects, you should always prefer “Feature Sliced Design” over “Simple Modular” architecture. As it really solves plenty of fundamental architectural issues almost without any cons.

In terms of simplicity and development speed, “Simple Modular” approach excels “FSD”. For MVPs and small, short-lived projects, the Simple Modular approach may be more appropriate.

If you want to learn “Feature Sliced Design” deeper, feel free to check out the official documentation.