Сравнение FEOD с другими подходами

FEOD не является «серебряной пулей». В нём заложена вариативность, и вы можете адаптировать подход под свои нужды. Мы постарались объединить сильные стороны других методологий и минимизировать слабые. Конечно же, всё ещё приходится идти на определённые компромиссы.

FEOD vs FSD (Feature-Sliced Design)

Важно

FEOD не является вариацией FSD — это отдельная методология со своей философией и подходом к организации проекта. Хотя определённые сходства всё-таки есть.

Общие черты

• Оба используют горизонтальные разрезы (уровни / слои)
• Оба имеют строгие правила импорта между уровнями
• Оба подходят для крупных проектов
• Оба ориентированы на фронтенд-разработку

Основные различия

Структура FSD:

• src
  • app
  • pages
  • widgets
  • features
  • entities
  • shared

Слой processes исключён: в актуальной спецификации FSD он помечен устаревшим.

Ключевые отличия от FEOD

1. Упрощённая структура

   • FEOD использует меньше уровней (5 против 7 в FSD)
   • Модули FEOD занимают место features, widgets и entities из FSD, но это не слой, а рекурсивный контейнер: модули одного уровня могут зависеть друг от друга через публичный API
   • Это снижает когнитивную нагрузку при принятии решений
   • В FEOD есть уникальный уровень globals, который не имеет аналога в FSD и берёт на себя роль описания сущностей, которые нигде не импортируются

2. Фрактальность

   • FEOD поддерживает вложенные модули без ограничения глубины
   • FSD имеет более жёсткую структуру слайсов
   • FEOD позволяет переносить pages внутрь modules и создавать приватные модули для страниц

3. Универсальность

   • FSD — решение, заточенное под фронтенд-проекты
   • FEOD — заточен под фронтенд, но легко адаптируется под другие платформы и задачи

4. Связанность

   • В FSD 2.1 код сначала лежит в страницах и выносится вниз при переиспользовании, поэтому связи появляются позже и привязаны к страницам; в FEOD бизнес-область группируется сразу
   • В FEOD модули имеют более высокую сцепленность, что упрощает понимание структуры
   • В FEOD важно, чтобы связанные сущности были как можно ближе друг к другу
   • При этом сложнее вынести переиспользуемые части «ниже по абстракции», так как в FEOD нет такого детального дробления, как в FSD

5. Нижний уровень: common и shared

   • Оба стоят внизу графа зависимостей и ничего не импортируют из других слоёв, но роль у них разная
   • shared в FSD — постоянная база, из которой строятся остальные слои. В 2.1 он тоже наполняется извлечением из страниц, но то, что туда попало, обычно остаётся там
   • common в FEOD — перевалочный пункт для сущностей, которые ещё не оформились в модуль. Когда это происходит, они уходят в модуль
   • Поэтому common держат тонким: индексные файлы не рекомендуются, глубина ограничена, а UI-кит и дизайн-система чаще живут в отдельном модуле. Подробнее в Common

6. Связи на одном уровне

   • В FSD слайсы одного слоя друг друга не импортируют (для entities есть исключение @x; у shared и app нет слайсов). Изоляцию слайсов обеспечивает сама структура слоёв
   • В FEOD модули одного уровня могут зависеть друг от друга через публичный API, а pages и app никто не импортирует. Здесь границу обеспечивают правила: публичный API, запрет zigzag-импортов, видимость подмодулей, проверка циклов (включается в конфигурации) и IoC для обратных связей
   • Гарантии FSD сильнее на верхних слоях; FEOD оставляет эту свободу модулям и требует проверок
   • Связанные модули в FEOD чаще не оставляют пирами, а вкладывают: подмодуль превращает горизонтальную связь в вертикальную. FSD распутывает связи, опуская общее вниз, FEOD вкладывает связанное внутрь

7. Набор слоёв

   • В FSD стандартный набор слоёв задан спецификацией, собственные слои выходят за её рамки
   • В FEOD набор слоёв и разрешённые связи между ними настраиваются (layers), а backend-набор показывает ветвление (routes и middlewares параллельны). Гарантии при этом становятся локальными для проекта. Подробнее в модификациях

FSD 2.1: «pages first»

На схеме слои двух подходов похожи: app → pages → modules → common у FEOD и app → pages → widgets → features → entities → shared у FSD. Но начиная с версии 2.1 FSD рекомендует начинать с кода в страницах и выносить его в нижние слои только при реальном переиспользовании. На практике дерево FSD схлопывается до app → pages, а widgets, features, entities и shared появляются по мере необходимости.

FEOD первичным разрезом делает не страницу, а модуль: app → modules, а страницы живут внутри модулей (pages in modules). Страницы верхнего уровня остаются там, где они действительно собирают композицию из нескольких модулей.

Pages first в FEOD тоже достижим: приватные модули страницы (pages/_home/) хранят логику одной страницы, а правило pages-private-modules не даёт импортировать их снаружи. Когда логика понадобится ещё где-то, такой модуль переносится в modules. Но основным рекомендованным путём остаются страницы внутри модулей; приватные модули лучше подходят для однофайловых компонентов (Vue, Svelte) и не стоит ими злоупотреблять. Выбор за командой.

Принцип у подходов общий: держать код рядом, пока его не нужно разделять. Отличается то, рядом с чем он лежит:

	FSD 2.1	FEOD
Единица владения кодом	Страница	Модуль (бизнес-область)
Куда растёт код	Вниз: из страницы в нижние слои при переиспользовании	Внутрь: в подмодули, и наружу: в другой модуль или common
Решение, которое остаётся за разработчиком	Когда и в какой слой выносить	Что считать модулем и где его границы
Слабое место	Страницы с общей бизнес-логикой дублируют её или расходятся до момента выноса	Больше связей между модулями (подмодули их сокращают, но только для древовидных); нужна дисциплина границ

Мы не считаем, что один из вариантов объективно лучше. Pages first проще в начале пути. Модульный разрез сразу группирует код по бизнес-области, но требует решения, что считать модулем.

В обоих подходах границу нельзя вычислить императивно: когда выделять модуль или подмодуль, оставлять ли код в common или на странице. Есть два практических ориентира: количество связей между сущностями (чем плотнее они сцеплены, тем вероятнее, что это один модуль) и отсутствие бизнес-логики (то, что её не содержит, кандидат в common). Они помогают оценить границу, но решение остаётся за командой, а правила импортов страхуют только от нарушения уже выбранных границ.

Когда выбрать FSD

• Если вы хотите избегать циклических зависимостей и максимально изолировать уровни друг от друга
• Вам ближе подход «начни со страницы»: код живёт в pages и выносится ниже при реальном переиспользовании
• Вы хотите готовую терминологию и большое сообщество вокруг методологии
• Вы хотите строгую иерархию уровней и импортов между ними

Когда выбрать FEOD

• Вам нужна гибкость, а идеи модульной архитектуры вам ближе
• Большие масштабируемые проекты с большим количеством функций
• Небольшие проекты тоже легко адаптируются под FEOD

FEOD vs Atomic Design

Atomic Design — предшественник FSD и feature-based подходов. Однако сам по себе Atomic Design не является методологией и не даёт чётких правил по организации проекта. Он скорее декларирует уровни абстракции, сосредоточиваясь на компонентах и их иерархии.

Идеи, лежащие в Atomic Design, легко визуализировать и представить схематично: есть базовые «кирпичики», из которых строятся более сложные конструкции. Он и создавался для описания пользовательского интерфейса и его элементов.

Однако в реальности элементы в проекте имеют куда более сложную структуру и взаимосвязи между собой. Кроме того, он слабо объясняет, как описывать и соединять логику между элементами. В итоге Atomic Design отлично ложится на идеи веб-дизайна, но плохо подходит для фронтенд-проектов как таковых.

Общие черты

• Оба подхода имеют определённые уровни
• Оба стремятся к изоляции и переиспользуемости сущностей

Основные различия

Структура Atomic Design:

• src
  • components
    • atoms
    • molecules
    • organisms
    • templates
  • pages

Ключевые отличия

1. Фокус

   • Atomic Design полностью сосредоточен на компонентах и их иерархии
   • FEOD фокусируется на связанности и логической близости сущностей, которые могут быть как компонентами, так и другими элементами (модули, страницы)

2. Бизнес-логика

   • Atomic Design фокусируется в основном на представлении, не предоставляя чётких указаний по организации бизнес-логики
   • FEOD сосредотачивается на выделении логических блоков (модулей) и их взаимодействии. Содержимое модулей может быть любым и зависит от ваших задач.

3. Масштабируемость

   • Atomic Design может стать сложным для управления в очень крупных проектах
   • FEOD предлагает более гибкую структуру для крупных проектов благодаря модульности

4. Разграничение

   • В Atomic Design иногда трудно определить, к какому уровню относится конкретный компонент
   • В FEOD правила размещения более однозначны

Когда выбрать Atomic Design

• Когда мало логики и хочется ощущения «конструктора»
• Когда хочется сосредоточиться на визуальном понимании в проекте

Когда выбрать FEOD

• Нужна организация не только UI, но и бизнес-логики
• Проекты с комплексной функциональностью
• Нужна более гибкая структура для крупных проектов

На самом деле содержимое модулей в FEOD может быть близко к уровням из Atomic Design: атомы, молекулы, организмы, шаблоны, страницы. При желании вы можете использовать Atomic Design как инструмент для организации внутри модулей. Но «биологичность» в названиях не несёт особой пользы и не рекомендуется.

FEOD vs Модульная архитектура

Сравнение не является прямым сопоставлением FEOD и классической модульной архитектуры, потому что FEOD и есть её вариация. Поэтому мы сравним FEOD с «классической» модульной архитектурой.

Общие черты

• Оба подхода организуют код вокруг функциональных модулей
• Оба обеспечивают изоляцию функциональности
• Оба подходят для средних и крупных проектов

Основные различия

Структура классической модульной архитектуры:

• src
  • modules
    • Auth
    • Products
  • common
  • router
  • store

Ключевые отличия

1. Дополнительные уровни

   • FEOD добавляет уровни app, pages и globals для более чёткой организации
   • Классическая модульная архитектура обычно более простая

2. Правила импорта

   • FEOD имеет более строгие правила импорта между уровнями
   • Классическая модульная архитектура может быть более гибкой, но менее контролируемой

3. Фрактальность

   • FEOD поддерживает вложенные модули (подмодули)
   • Классическая модульная архитектура обычно имеет плоскую структуру модулей или, наоборот, может скатываться в хаотичные вложенности

4. Страницы

   • FEOD выделяет страницы в отдельный уровень
   • В классической модульной архитектуре страницы могут быть частью модулей или отдельной папкой

Когда выбрать классическую модульную архитектуру

• Вам принципиально не нравится, как работает FEOD

Когда выбрать FEOD

• Нужны чёткие правила и контроль над зависимостями
• Проект может вырасти в крупный
• Нужен туллинг и документация для команды

FEOD vs Плоская архитектура

Общие черты

• Оба подхода просты для понимания новичками
• Оба позволяют быстро начать разработку

Основные различия

Плоская архитектура:

• src
  • components
  • views
  • utils
  • store
  • router

Ключевые отличия

1. Организация

   • Плоская архитектура группирует файлы по типу
   • FEOD группирует по функциональности и роли

2. Масштабируемость

   • Плоская архитектура плохо масштабируется
   • FEOD хорошо масштабируется благодаря модульности

3. Связанность

   • В плоской архитектуре компоненты часто тесно связаны
   • FEOD обеспечивает лучшую изоляцию через модули

4. Поддержка

   • В плоской архитектуре сложно поддерживать крупные проекты
   • FEOD упрощает поддержку через чёткую структуру

Когда выбрать плоскую архитектуру

• Очень маленькие проекты или прототипы
• Проекты с ограниченным сроком жизни
• Учебные проекты

Когда выбрать FEOD

• Проекты, которые будут развиваться
• Нужна хорошая организация кода
• Планируется работа нескольких разработчиков

Сравнительная таблица

Критерий	FEOD	FSD	Atomic Design	Модульная	Плоская
Сложность внедрения	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐	⭐
Масштабируемость	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐
Тестируемость	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐
Понятность для новичков	⭐⭐⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
Гибкость	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐
Подходит для малых проектов	⭐⭐	⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
Подходит для крупных проектов	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐
Поддержка бизнес-логики	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐	⭐⭐
Строгость правил	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	⭐⭐	⭐

Выводы

FEOD — это попытка найти баланс между строгими архитектурными методологиями и реальными нуждами команд. Он объединяет сильные стороны Atomic Design, FSD и модульного подхода, но избавлен от перегруженной терминологии и лишних правил.

Благодаря модульности, чётким уровням и принципу фрактальности FEOD одинаково хорошо работает как в небольших проектах, так и в масштабных системах, которые со временем обрастают функциональностью.

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

FEOD не обещает «серебряной пули», но даёт то, чего часто не хватает в реальной практике: ясность, гибкость и масштабируемость без лишней сложности.