WARNING

Эта статья сгенерирована AI и требует ручной доработки.

FEOD для бэкенда и BFF

FEOD можно применять не только во фронтенде. Для BFF и серверных приложений подход полезен тем же самым: структура предсказуема, правила импорта понятны, масштабирование не превращает проект в хаос.

Ниже — минимальная, но достаточная модель уровней и правил для бэкенда.

Базовые уровни

• app: bootstrap приложения, интеграции, конфигурации, точка входа.
• routes: маршруты (часто file-based routing).
• middlewares: middleware уровня приложения.
• modules: бизнес-логика и доменные модули.
• global: сущности без импорта (типы, полифиллы, расширения интерфейсов).

Направление импорта

Главный принцип остаётся тем же: верхние уровни знают о нижних, но не наоборот.

app -> (routes | middlewares) -> modules
global не импортируется

Дополнительно:

• routes и middlewares не импортируют друг друга.
• модули импортируются только через index.ts.
• внутренние файлы модуля не импортируются извне.

Пример структуры

src/
  app/
    entry.ts
    integrations/
      db.ts
      router.ts
  routes/
    index.ts
    users/
      [id].ts
  middlewares/
    auth.ts
  modules/
    Users/
      index.ts
      api/
      services/
      types/
      modules/
        Sessions/
          index.ts
  global/
    types.d.ts

Как это выглядит в BFF

BFF часто строится вокруг маршрутов и адаптации данных для фронтенда. FEOD помогает держать границы:

• routes: только адаптация запроса/ответа, маппинг DTO, валидация.
• modules: бизнес-логика, доступ к данным, доменные правила.
• middlewares: авторизация, трассировка, логирование.
• app: сборка всего вместе, подключение инфраструктуры.

Такой подход позволяет легко менять реализацию внутри модуля, не ломая маршруты.

Когда выделять подмодуль

Если модуль разрастается, используйте фрактальность:

modules/
  Billing/
    modules/
      Invoices/
      Payments/

Подмодули имеют те же правила: собственный index.ts, изоляция, отсутствие глубоких импортов.

Где держать типы

• Если типы используются внутри одного модуля — остаются в модуле.
• Если типы нужны без импорта по всему проекту — в global.
• Если типы универсальные, но с импортом — можно вынести в отдельный модуль (например, SharedTypes).

Итог

FEOD для бэкенда сохраняет ключевые свойства методологии:

• чёткие уровни;
• ограничение связности;
• предсказуемая структура;
• возможность роста без пересмотра уровней.

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