Краткое введение
Вы находитесь в разделе быстрого введения в FEOD. Здесь вы найдёте основные концепции и принципы, которые лежат в основе методологии. Если вы хотите глубоко разобраться в методологии, понять философию FEOD, причины принятых решений и контекст, в котором она была создана, начните с полного введения.
FEOD — Fractal Entity Oriented Design — это методология организации структуры фронтенд-проектов, которая сочетает в себе слоистый и модульный подходы. Она разработана для решения проблем современной фронтенд-разработки.
Важный момент, который хочется заранее обозначить: в первую очередь FEOD — это попытка найти разумное описание модульной архитектуры и дать ей документацию и полноценный инструментарий. Если вы уже используете нечто похожее на модульную архитектуру, то FEOD может показаться вам знакомым, а одна из его возможных вариаций может описать ваш подход. Таким образом вы сможете получить документацию для своего подхода, а также использовать инструменты FEOD в вашем случае.
Основные концепции
Модульность
Модуль — это независимая часть проекта, которая имеет свою структуру, правила и поведение. Каждый модуль можно рассматривать как зависимость.
Модули — это центральная идея FEOD, и по факту всё остальное — лишь инструменты для её реализации. Поэтому важно уделить им особое внимание.
Фрактальность
Фрактальность — это способ организации кода, который позволяет создавать вложенные структуры без ограничения глубины. В FEOD фрактальность — это свойство модулей.
Если вас пугает возможность слишком глубоких вложений, не переживайте. Каждое вложение должно быть обоснованным, и более трёх уровней вложения крайне не рекомендуется.
Сущность-ориентированность
Каждый файл или директория в проекте рассматривается как сущность с определённой ролью. Это помогает быстро понять назначение и ограничения каждой части проекта. Не стоит наделять особым смыслом понятие сущности. Это просто принятое определение, которое будет использоваться повсеместно для обозначения сущностей в файловой системе.
Сущность — это любой файл или директория в проекте, имеющий свою роль (не путать с понятием «сущность» в контексте DDD).
- Сущности для проекта — это как типизация для файлов и директорий проекта, позволяющая чётко ограничить возможные наименования и правила для конкретной сущности
- Роль сущности полностью определяет её поведение. Это позволяет быстро во время ревью определить, что к чему, и ограничить возможность потенциальных ошибок
- Эти правила для сущностей позволяют проектам оставаться в одном стиле и с одинаковыми наименованиями
Уровни
Уровень — это понятие для описания всех вложенных сущностей в другую сущность.
Здесь опять же нет особого термина — это просто принятое определение для обозначения местоположения сущностей в файловой системе. Например, уровень modules: все вложенные сущности — это модули. Также могут быть уровни pages, common, global и другие.
Ограничения импортов
Для того чтобы избежать циклических зависимостей и других проблем, существуют ограничения на импорты между уровнями. У каждого уровня есть свои правила.
Основные правила
Теперь, когда мы определились с основными концепциями, можем описать ими структуру приложения.
Всё строится от сущностей верхних уровней:
- app — уровень, в котором описаны вход в приложение и его настройка. По сути это bootstrap приложения.
- pages — отвечает за страницы приложения. Они работают по правилам, схожим с файловым роутингом, но вовсе не принуждают его использовать.
- modules — уровень, где описаны модули с логикой в приложении. Модули — это независимые части приложения, которые могут использоваться в других частях приложения.
- common — уровень общих данных и логики в приложении. Этот уровень не связан с бизнес-логикой и может быть использован в других частях приложения.
- global — уровень, на котором определяются глобальные данные. На этом уровне обычно определяются глобальные типы, полифиллы, shim и другие данные, которые не должны быть импортированы в другие части приложения.
У каждой сущности свои чёткие роли и правила. Самое главное правило:
- App не импортируется никем и является входной точкой в приложение
- App может импортировать common, modules и pages
- Pages импортируются только из app и могут импортировать common и modules
- Modules могут импортировать common и другие modules (только через публичный API,
index.ts) - Common может импортироваться из modules, pages и app
- Global нигде не импортируется, так как там объявляются и расширяются глобальные сущности
Итого цепочка: common ➜ modules ➜ pages ➜ app | Global — не импортируется никуда
Что дальше?
Вы уже знаете азы работы с FEOD. Возможно, вы захотите ознакомиться с полноценным введением. Или можете начать изучать структуру проекта, где подробно рассмотрены все уровни и особенности работы с ними.