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

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

FEOD vs FSD (Feature-Sliced Design)

Важно

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

Общие черты

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

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

Структура FSD:

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

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

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

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

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

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

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

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

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

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

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

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

Когда выбрать 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 не обещает «серебряной пули», но даёт то, чего часто не хватает в реальной практике: ясность, гибкость и масштабируемость без лишней сложности.