Beta Документация для beta‑теста, возможны ошибки и неточности.
Перейти к содержимому

Краткое введение

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

FEODFractal Entity Oriented Design — это методология организации структуры фронтенд-проектов, которая сочетает в себе слоистый и модульный подходы. Она разработана для решения проблем современной фронтенд-разработки.

Важный момент, который хочется заранее обозначить: в первую очередь FEOD — это попытка найти разумное описание модульной архитектуры и дать ей документацию и полноценный инструментарий. Если вы уже используете нечто похожее на модульную архитектуру, то FEOD может показаться вам знакомым, а одна из его возможных вариаций может описать ваш подход. Таким образом вы сможете получить документацию для своего подхода, а также использовать инструменты FEOD в вашем случае.

Основные концепции

Модульность

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

Модули — это центральная идея FEOD, и по факту всё остальное — лишь инструменты для её реализации. Поэтому важно уделить им особое внимание.

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

Фрактальность — это способ организации кода, который позволяет создавать вложенные структуры без ограничения глубины. В FEOD фрактальность — это свойство модулей.

  • modules
    • UserManagement
      • modules
        • UserProfile
          • modules
            • AvatarUpload

Если вас пугает возможность слишком глубоких вложений, не переживайте. Каждое вложение должно быть обоснованным, и более трёх уровней вложения крайне не рекомендуется.

Сущность-ориентированность

Каждый файл или директория в проекте рассматривается как сущность с определённой ролью. Это помогает быстро понять назначение и ограничения каждой части проекта. Не стоит наделять особым смыслом понятие сущности. Это просто принятое определение, которое будет использоваться повсеместно для обозначения сущностей в файловой системе.

Сущность — это любой файл или директория в проекте, имеющий свою роль (не путать с понятием «сущность» в контексте 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 нигде не импортируется, так как там объявляются и расширяются глобальные сущности

Итого цепочка: commonmodulespagesapp | Global — не импортируется никуда

Что дальше?

Вы уже знаете азы работы с FEOD. Возможно, вы захотите ознакомиться с полноценным введением. Или можете начать изучать структуру проекта, где подробно рассмотрены все уровни и особенности работы с ними.