Feature-Sliced Design (FSD): Основы и практические примеры архитектуры

Когда я только начинал свою карьеру фронтенд-разработчика, часто сталкивался с проблемами поддержки кода в проектах. Со временем я понял, что структура кода имеет решающее значение. Так я узнал о Feature-Sliced Design. Этот подход помогает разбивать проект на функциональные части, что упрощает работу с кодом и его сопровождение. Давайте разберемся как это работает.

Основные принципы Feature-Sliced Design

FSD (Feature-Sliced Design) нужен для удобной организации кода, особенно в больших проектах, и даёт несколько ключевых преимуществ:

1. Понятность: код разбит на независимые модули (например, авторизация, профиль), что делает структуру логичной и облегчает навигацию.

2. Поддерживаемость: каждый модуль ограничен своей зоной ответственности, что упрощает изменения — работа над одной фичей не ломает другую.

3. Переиспользуемость: изолированные компоненты и логика могут быть легко использованы в других частях приложения без дублирования.

4. Масштабируемость: новые функции можно добавлять как отдельные модули, не нарушая структуру кода.

5. Удобство тестирования: с четкими границами модулей проще писать и поддерживать тесты.

Описание структуры слоев и папок

1. App

• Назначение: Слой для инициализации приложения.

• Содержит: Глобальные настройки (например, темы), роутинг, провайдеры контекста.

• Пример: App.tsx, AppRouter.tsx.

2. Entities

• Назначение: Здесь хранятся бизнес-сущности — основные модели и их логика.

• Содержит: Определения сущностей (например, User, Product), бизнес-логику, которая их касается.

• Пример: entities/User, entities/Product.

3. Features

• Назначение: Модули, которые реализуют конкретные пользовательские действия.

• Содержит: Компоненты, хуки и логику, которая выполняет задачу для пользователя, например, авторизацию или добавление товара в корзину.

• Пример: features/Login, features/AddToCart.

4. Shared

• Назначение: Общие утилиты, типы и компоненты, которые используются в разных частях приложения.

• Содержит: Переиспользуемые компоненты (например, кнопки), утилиты, глобальные типы.

• Пример: shared/Button, shared/hooks, shared/utils.

5. Pages

• Назначение: Собирает все компоненты, чтобы сформировать страницы приложения.

• Содержит: Страницы, которые используют features, entities и shared слои, чтобы создавать полноценные представления.

• Пример: pages/HomePage, pages/ProductPage.

6. Widgets

• Назначение: Крупные, повторяющиеся блоки, которые можно переиспользовать на разных страницах.

• Содержит: Модули с логикой и UI (например, блоки новостей, карусели).

• Пример: widgets/NewsCarousel, widgets/UserProfile.

7. Processes (опционально)

• Назначение: Сюда можно выносить сложные процессы, включающие несколько фич.

• Содержит: Бизнес-процессы, если такие есть (например, процесс оформления заказа).

• Пример: processes/Checkout.

Пример структуры React-приложения для Интернет-магазина:

src/ ├── app/                        // Глобальные настройки приложения │   ├── store.js               // Настройка Redux store, подключение middleware и т.д. │   └── rootReducer.js         // Главный редьюсер, который объединяет все слайсы │ ├── pages/                      // Основные страницы приложения │   ├── HomePage/              // Главная страница │   │   ├── index.js           // Точка входа страницы для упрощённого импорта │   │   ├── HomePage.jsx       // Компонент главной страницы │   │   └── HomePage.module.css // Стили для главной страницы │   ├── ProductPage/           // Страница деталей товара │   │   ├── index.js │   │   ├── ProductPage.jsx │   │   └── ProductPage.module.css │   ├── CartPage/              // Страница корзины │   │   ├── index.js │   │   ├── CartPage.jsx │   │   └── CartPage.module.css │   └── CheckoutPage/          // Страница оформления заказа │       ├── index.js │       ├── CheckoutPage.jsx │       └── CheckoutPage.module.css │ ├── widgets/                    // Повторяющиеся UI-блоки, используемые на нескольких страницах │   ├── Header/                // Шапка сайта │   │   ├── index.js │   │   ├── Header.jsx │   │   └── Header.module.css │   ├── Footer/                // Подвал сайта │   │   ├── index.js │   │   ├── Footer.jsx │   │   └── Footer.module.css │   └── ProductList/           // Виджет со списком товаров │       ├── index.js │       ├── ProductList.jsx │       └── ProductList.module.css | ├── features/                   // Конкретные функции приложения, каждая из которых автономна │   ├── Product/               // Функционал работы с товарами │   │   ├── index.js           // Экспортирует компоненты и логику фичи │   │   ├── ProductSlice.js    // Redux slice для управления состоянием товаров │   │   └── Product.module.css │   ├── Cart/                  // Функционал работы с корзиной │   │   ├── index.js │   │   ├── CartSlice.js       // Redux slice для управления состоянием корзины │   │   └── Cart.module.css │   └── Auth/                  // Функционал авторизации пользователя │       ├── index.js │       ├── AuthSlice.js       // Redux slice для состояния пользователя (авторизация, токены и т.д.) │       └── Auth.module.css │ ├── processes/                  // Сложные бизнес-процессы, объединяющие фичи и виджеты │   ├── UserRegistration/      // Процесс регистрации пользователя │   │   ├── index.js │   │   ├── UserRegistration.jsx // Компонент регистрации с формами и валидацией │   │   └── UserRegistration.module.css │   ├── AddToCart/             // Процесс добавления товара в корзину │   │   ├── index.js │   │   ├── AddToCart.jsx      // Компонент добавления в корзину, включает логику для Cart │   │   └── AddToCart.module.css │   └── CheckoutProcess/       // Процесс оформления заказа │       ├── index.js │       ├── CheckoutProcess.jsx // Компонент оформления заказа с интеграцией оплаты │       └── CheckoutProcess.module.css │ ├── shared/                     // Общие компоненты, которые используются по всему проекту │   └── components/ │       ├── Button/            // Кнопка, переиспользуемая по всему приложению │       │   ├── index.js │       │   ├── Button.jsx │       │   └── Button.module.css │       ├── Input/             // Поле ввода, переиспользуемое в формах │       │   ├── index.js │       │   ├── Input.jsx │       │   └── Input.module.css │       └── Modal/             // Модальное окно для отображения уведомлений и подтверждений │           ├── index.js │           ├── Modal.jsx │           └── Modal.module.css │ └── utils/                      // Утилитарные функции и хелперы     ├── api.js                 // API-методы для взаимодействия с сервером     └── formatPrice.js         // Функция для форматирования цен, чтобы они выглядели красиво 

Поддержка модульности с алиасами и зависимостями

Модульная архитектура с алиасами и управлением зависимостями в FSD делает проект более структурированным и гибким для роста. Давайте разберём, как это работает и что важно учесть.

1. Алиасы для модулей

Алиасы в FSD позволяют упростить импорт, сократив длинные пути и изоляцию модулей. Это делается с помощью настройки tsconfig.json или webpack.config.js. В tsconfig.json, например, можно прописать алиасы следующим образом:

{   "compilerOptions": {     "baseUrl": "src",     "paths": {       "@app/*": ["app/*"],       "@entities/*": ["entities/*"],       "@features/*": ["features/*"],       "@shared/*": ["shared/*"],       "@pages/*": ["pages/*"],       "@widgets/*": ["widgets/*"],       "@processes/*": ["processes/*"]     }   } }

Теперь можно импортировать зависимости в модули по короткому пути, что делает код более читаемым и поддерживаемым.

import { UserModel } from "@entities/User"; import { AddToCard } from "@feature/AddToCard";

2. Изоляция модулей

Каждый модуль в FSD представляет собой отдельный слой ответственности. Например, entities служит для работы с бизнес-логикой и сущностями, features — для пользовательских функций, shared — для общих компонентов, доступных в приложении. Это изолирует логику и данные, ограничивая влияние изменений на весь проект.

3. Управление зависимостями

Важный принцип модульной архитектуры FSD — минимизация зависимости между модулями. Здесь поможет использование инверсии зависимостей (Dependency Injection) и управляемых экспортов. Например, экспортируем только те части модулей, которые нужны в других слоях, а частные элементы (вроде вспомогательных функций) скрываем внутри модуля.

4. Настройка зависимостей и разрешений

Чтобы избежать циклических зависимостей, FSD предполагает, что:

• Нижние слои (shared) могут быть импортированы в верхние слои (features, entities, pages).

• Верхние слои не могут напрямую импортировать друг друга. Например, features и entities должны общаться через слой shared или API.

Пример ограничения зависимостей:

Для управления доступом и зависимостями можно использовать ESLint с настройками правил для алиасов. В .eslintrc.json можно прописать правила для блокировки циклических и ненужных зависимостей.

Пример:

{   "rules": {     "no-restricted-imports": [       "error",       {         "paths": [           {             "name": "@features",             "message": "Avoid direct imports from features. Use only allowed layers."           }         ]       }     ]   } }

Типы и DTO (Data Transfer Objects)

В FSD типы и DTO обеспечивают строгую структуру данных и удобство при работе с API, особенно в масштабных проектах.

Типы

Типы описывают внутренние данные приложения и помогают избежать ошибок. Например, тип для пользователя может быть таким:

Пример:

export type Order = {     id: string;     date: string;     customer_name: string;     total_amount: number; };

DTO

DTO (Data Transfer Objects) описывают данные для обмена с API и отделяют их от внутренней структуры, что упрощает работу с изменениями на сервере.

Пример:

export type OrderDTO = {     id: string;     date: string;     customer_name: string;     total_amount: number; };

Maппинг DTO к типам

Маппинг преобразует DTO в нужный формат. Это удобно, когда данные API отличаются по структуре.

Пример:

export const mapUserDtoToUser = (dto: OrderDTO): Order => ({   id: dto.id,   date: dto.date,   customer_name: dto.customer_name,   total_amount: dto.total_amount, });

Зачем это нужно?

• Гибкость при изменении API: Корректируем только DTO и маппинг.

• Читаемость и строгая структура: Типы делают код понятнее.

• Защита внутренней структуры: DTO отделяют внутренние данные от внешних запросов.

Типы и DTO повышают стабильность и гибкость в работе с данными, делая архитектуру надежной.

Заключение

FSD — мощная архитектура, которая дает проекту чёткую структуру, особенно в масштабируемых приложениях. Разделение на слои (entities, features, pages, widgets и т.д.) позволяет изолировать модули, упрощая поддержку и развитие кода.

С использованием алиасов, DTO, строгой типизации и настройки зависимостей, FSD становится гибким инструментом для организации данных и логики. Это облегчило работу для нашей команды, минимизируя ошибки, упрощая адаптацию к изменениям и делая проект удобным для дальнейшего расширения.

P.S. Статья вынесена из песочницы в связи с получением приглашения.