BMAP — Base Multi Application Platform

Структура репозитория

<product>/
├── frontend/
│   ├── apps/<app>/             # продуктовые фронты (BMFP)
│   ├── microfrontends/<mfe>/   # микрофронтенды (BMFP), монтируются в shell
│   └── modules/<module>/       # source-first frontend-модули (BMFP/REUSE, опц.)
├── backend/
│   ├── services/<service>/     # бэки (BMBP)
│   └── gateways/<frontend>_gateway/  # шлюзы (BMGP, опц.), по одному на фронт
├── documentation/              # дока продукта
├── tools/                      # автоматизация репозитория
└── tests/                      # репо-уровневые / E2E (юнит-тесты — рядом со своим пакетом)

Каждый фронт/бэк/шлюз — самостоятельный пакет со своей обвязкой (контейнер, зависимости, секреты). BMAP отвечает только за корни и границы; имена файлов внутри пакета — по правилам его архитектуры.

Новый фронт → пакет в frontend/apps/ (и при необходимости свой шлюз в backend/gateways/). Новый бэк → пакет в backend/services/.

frontend/modules/ — локальные checkout переиспользуемых frontend-единиц. Логически такой модуль остаётся независимым соседним репозиторием, а не собственностью продукта; продукт лишь закрепляет его версию. Встроенный модуль собирается вместе с приложением. Независимо поставляемый UI с собственной точкой монтирования относится к frontend/microfrontends/.

Связь фронта и бэка

Фронт и бэк связаны только контрактом — формой данных, не общим кодом. Контракт — конверт:

• успех: { status, data, details? }
• ошибка: { status, error_code, details }

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

Слои фронта и бэка зеркальны по ролям:

Клиент в infrastructure фронта смотрит ровно в api бэка. Если есть шлюз — смотрит в шлюз, шлюз проксирует в бэки.

Поток запроса:

действие пользователя в boundary
  → domain.service (BMFP)
    → infrastructure.client ──конверт──▶ api (BMBP)
                                            → core.solution/service
                                              → infrastructure.repository → БД
                                          ◀── конверт ───
  ◀── DTO в store ── валидация ──┘
boundary перерисовывается

Варианты поставки

• Десктоп. Фронт (BMFP) в WebView + бэк как нативная оболочка (окно, IPC-вызовы, доступ к ОС). Отдельного API нет; «серверные» заботы свёрнуты в оболочку, BMBP остаётся ментальной картой.
• Контейнерный стек. БД → бэк (BMBP) → веб со статикой фронта, прокси отдаёт /api на бэк.
• Несколько бэков + шлюзы. Несколько BMBP-бэков, шина событий, шлюзы (по одному на каждый фронт, агрегируют ручки из нужных бэков), несколько BMFP-фронтов и MFE.

Граница (конверт) одинакова во всех вариантах.

Нативная оболочка вместо BMBP

Когда отдельного API нет, бэкенд — это нативная оболочка. Понятия BMBP проецируются так:

Когда появляется настоящий BMBP-бэк — он добавляется отдельным пакетом в backend/services/.

Заведение нового продукта

1. Создать корни: frontend/, backend/, documentation/, tools/, tests/.
2. Согласовать контракт: конверт { status, data, details? } и DTO ключевых сущностей.
3. Поднять бэк по BMBP (или нативную оболочку, если API не нужен).
4. Поднять фронт по BMFP, клиент infrastructure нацелить на бэк (или шлюз).
5. Выбрать упаковку (десктоп / контейнерный стек / несколько бэков + шлюзы), описать в documentation/.

Порядок: сначала контракт, потом независимое наполнение частей, потом сборка в поставку.