Структура проекта: по типам и по фичам

↑ 8.2 Архитектура фронтенда и паттерны · ← Предыдущая · → Следующая

Желательно~3 мин чтенияУровень: senior

Зачем это на собесе

Организация кода влияет на скорость разработки; спрашивают, как вы масштабируете структуру.

По типам (layer-based)

src/
  components/
  composables/
  stores/
  services/
  views/
  utils/

Плюсы: просто, привычно для небольших проектов. Минусы: одна фича размазана по 5 папкам, растут «свалки» (components на 300 файлов), трудно вынести фичу.

По фичам (feature-based)

src/
  features/
    orders/
      components/
      composables/
      api.ts
      store.ts
      types.ts
      index.ts       # публичный API фичи
    users/
  shared/
    ui/
    lib/
    api/
  app/

Плюсы: всё по теме рядом, легко удалить или вынести, командные границы. Минусы: нужна дисциплина по общему коду.

Правила

• фича не импортирует внутренности другой фичи, только её index.ts;
• общее в shared, а доменное — в фичах;
• запрет циклических импортов (import/no-cycle);
• границы проверять линтером (eslint-plugin-boundaries, dependency-cruiser);
• алиасы (@/features/orders).

Гибрид

Общие UI-компоненты — по типам в shared/ui, домен — по фичам.

Когда что

Размер	Выбор
Маленький проект	по типам
Средний, несколько разработчиков	по фичам
Большой, несколько команд	FSD или monorepo с пакетами

Вопросы с ответами

Почему по фичам лучше при росте?

Изменение затрагивает одну папку, ясные границы, проще владение командой и ленивая загрузка по фиче.

Как не превратить shared в свалку?

Ввести правило: в shared только то, что нужно минимум двум фичам, и без знаний о домене.