Какие плюсы и минусы FSD?

Какие плюсы и минусы FSD?

FSD (Feature-Sliced Design) — это архитектурная методология для организации кода в фронтенд-приложениях. Давайте рассмотрим её преимущества и недостатки.

Что такое FSD?

FSD структурирует проект по слоям (layers) и срезам (slices), где каждый слой отвечает за конкретный уровень абстракции:

src/
├── app/          # Инициализация приложения
├── processes/    # Сложные сценарии (мультишаговые операции)
├── pages/        # Страницы приложения
├── widgets/      # Комплексные компоненты (вся страница или её часть)
├── features/     # Отдельные функции приложения
├── entities/     # Бизнес-сущности (user, post, product)
├── shared/       # Переиспользуемые утилиты и компоненты
└── segments/     # Опциональный слой (для случайных кусков UI)

Плюсы FSD

1. Высокая масштабируемость

Структура масштабируется вместе с проектом:

features/
├── auth/
│   ├── ui/        # Компоненты
│   ├── model/     # Состояние (store, hooks)
│   ├── api/       # API запросы
│   ├── lib/       # Утилиты
│   └── types/     # TypeScript типы
├── profile/
├── comments/
└── notifications/

Приложение с 50 фичами остаётся организованным.

2. Чёткие границы ответственности

Каждый слой и срез имеет одну задачу:

// entities/user/model/store.ts — только бизнес-логика user
export const useUser = () => { /* ... */ };

// features/auth/ui/LoginForm.tsx — UI для login
export function LoginForm() { /* ... */ }

// widgets/UserCard.tsx — комбинирует entities и features
export function UserCard({ userId }) { /* ... */ }

3. Предотвращение циклических зависимостей

Правило: зависимости только в сторону внутренних слоёв:

// ✅ Правильно: features зависит от entities
features/auth/model → entities/user

// ❌ Неправильно: entities не должна зависеть от features
entities/user → features/auth // ЗАПРЕЩЕНО

4. Простота переиспользования

Компоненты и логика переиспользуются через публичные API:

// shared/ui/Button/index.ts — экспортирует только Button
export { Button } from './Button';

// Импорт всегда одинаков
import { Button } from '@/shared/ui/Button';

5. Упрощение командной разработки

Разные разработчики работают над разными фичами без конфликтов:

✅ Разработчик 1: features/auth/
✅ Разработчик 2: features/profile/
✅ Разработчик 3: features/comments/
✅ Разработчик 4: shared/ui/

Минусы FSD

1. Высокая начальная сложность

Медленный старт, много папок для малого проекта:

// Для простого приложения это может быть перебором
src/
├── app/
├── pages/
├── features/
│   └── todo/      # Для одной фичи
├── entities/
│   └── todo/      # Повторная структура
└── shared/
    ├── ui/
    ├── lib/
    └── types/

2. Много файлов на одну фичу

Навигация может быть утомительной:

features/auth/
├── ui/
│   ├── LoginForm.tsx
│   ├── RegisterForm.tsx
│   ├── LoginForm.module.css
│   └── RegisterForm.module.css
├── model/
│   ├── authStore.ts
│   ├── useAuth.ts
│   └── authSelectors.ts
├── api/
│   └── authApi.ts
├── lib/
│   └── validateEmail.ts
├── types/
│   └── auth.types.ts
└── index.ts

3. Оверинжиниринг для простых проектов

Обычные CRUD приложения не нуждаются в такой структуре:

// FSD для простого TODO app — излишне сложно

// Более простой подход работает так же хорошо:
src/
├── components/
├── pages/
├── hooks/
├── services/
└── types/

4. Сложность разделения ответственности

Иногда неясно, куда поместить код:

// Валидация email — в shared/lib или в features/auth/lib?
// Иконка для user — в shared/ui или в entities/user/ui?
// Утилита для форматирования даты — в shared/lib или в features/calendar/lib?

5. Много index.ts файлов

Экспорты могут стать кошмаром:

// Re-exports в каждом index.ts
src/shared/ui/index.ts
src/shared/lib/index.ts
src/entities/user/index.ts
src/entities/user/ui/index.ts
src/entities/user/model/index.ts
// и так далее...

6. Зависимость от инструментов

Для enforce правил нужны дополнительные инструменты:

// eslint-plugin-import-access нужен для проверки правил
import { something } from '@/features/auth/model/internal'; // ❌ Warning!

// Без инструмента это контролируется вручную

Когда использовать FSD

✅ Используй FSD если:

• Средний или крупный проект (50+ фич)
• Командная разработка (3+ человека)
• Долгосрочное поддержание кода
• Сложная бизнес-логика
• Масштабирование предсказуемо

❌ Не используй FSD если:

• Маленький проект (5-10 фич)
• Один разработчик
• Быстрый прототип
• MVP или hack
• Начинают учиться

Альтернативные архитектуры

// 1. Простая структура
src/
├── components/
├── pages/
├── hooks/
├── utils/
└── types/

// 2. По типам (component/page/hook)
src/
├── components/
├── pages/
├── hooks/
└── services/

// 3. По доменам (domain-driven design)
src/
├── auth/
├── user/
├── post/
└── shared/

// 4. Composable Architecture
src/
├── modules/
│   ├── auth/
│   ├── user/
│   └── shared/

Практический пример FSD структуры

src/
├── app/
│   ├── App.tsx
│   └── providers.tsx
├── pages/
│   ├── HomePage.tsx
│   └── ProfilePage.tsx
├── widgets/
│   └── UserCard/
│       ├── ui/
│       │   └── UserCard.tsx
│       └── index.ts
├── features/
│   └── auth/
│       ├── ui/
│       │   └── LoginForm.tsx
│       ├── model/
│       │   ├── authStore.ts
│       │   └── useAuth.ts
│       ├── api/
│       │   └── authApi.ts
│       └── index.ts
├── entities/
│   └── user/
│       ├── ui/
│       │   └── UserAvatar.tsx
│       ├── model/
│       │   └── userStore.ts
│       └── index.ts
└── shared/
    ├── ui/
    │   ├── Button/
    │   └── Input/
    ├── lib/
    │   ├── api.ts
    │   └── validators.ts
    └── types/
        └── common.ts

Итоги

FSD — мощная архитектура, но не серебряная пуля:

Плюсы:

• Масштабируемость
• Чёткие границы
• Предотвращение циклических зависимостей
• Удобство командной разработки
• Упрощение рефакторинга

Минусы:

• Высокая начальная сложность
• Много файлов
• Оверинжиниринг для малых проектов
• Неясные границы между слоями
• Зависимость от инструментов

Выбирай архитектуру в соответствии с размером проекта, не наоборот.