Микрофронтенды без боли: домены, контракты, дизайн-система и релизы

Микрофронтенды — инструмент организационной масштабируемости, а не модная архитектура «для всех». Мы предлагаем их тогда, когда командам реально нужна независимость релизов и стеков, а продукт распадается на чёткие домены: каталог, поиск, заказ, кабинет, админка. В этой статье — как мы режем границы, как собираем композицию в Next.js, где уместен Module Federation, как договориться о контрактах и разделить дизайн-систему, чтобы не потерять производительность и наблюдаемость.

1) Когда микрофронтенд действительно нужен

Признаки: несколько автономных команд, отдельные Roadmap'ы, разные циклы релизов, интеграции с «своими» бэкендами, долгий цикл согласований в монолите. Если проект маленький или команда одна — выберите модульную монолитную архитектуру, не усложняйте жизнь ни себе, ни пользователям.

2) Границы: по доменам, а не по страницам

Режем по бизнес-доменам, которые владеют своими API/правами/событиями: «Каталог», «Оформление заказа», «Кабинет», «Админка». Каждый домен поставляет UI-модуль и «порт» для интеграции: контракты типов/событий, ограничения зависимостей, версии. Границы не должны пересекаться; общие элементы идут в платформу (shell).

3) Композиция в Next.js: shell + модули

В App Router мы собираем «shell» приложения (роутинг, шапка/футер, аутентификация, дизайн-токены) и подмешиваем модули: через маршруты (remote routes), через динамический импорт компонентов, через Module Federation для рантайм-композиции. Важно: «критический путь» (навигация, вход, корзина) должен оставаться под контролем оболочки, иначе ухудшится UX и поддержка.

Подходы к композиции

• Build-time: модули подключаются на сборке; просто и быстро, но релизы связаны.
• Runtime (MF): грузим удалённые бандлы; независимые релизы, но сложнее кэш и observability.
• SSR/Streaming модулями: shell стримит контейнер, модули подгружаются по готовности.

4) Контракты компонентов и событий

Модули общаются через стабильные интерфейсы: типы пропсов, события/команды («addToCart», «checkoutComplete»), контракты ошибок. Сильно помогает «портовая» модель: shell объявляет интерфейсы, модули реализуют. Для асинхронных сценариев — событийная шина с именованными каналами и схемами полезной нагрузки. Важны версионирование и обратная совместимость.

5) Дизайн-система и токены

Чтобы модули «не расползались», дизайн-токены и базовые компоненты живут в платформе: цвета, отступы, типографика, формы, таблицы, графики. Обновления приходят как версионированные пакеты; модули не тянут собственные UI-фреймворки без причины. Для критичных элементов проверяем визуальные контракты (storybook + визуальная регрессия).

6) Роутинг и данные

Роутинг остаётся в shell: он знает, какой модуль отрисовать и как сформировать URL/метаданные. Данные: модуль ходит к своему BFF/API, но соблюдает правила кэша/инвалидаций и trace-корреляции. Кросс-модульные данные (например, авторизация, корзина) — сервисы платформы, а не «общая переменная».

7) Перфоманс и бандлы

Риск microfrontends — раздутые бандлы и дубли зависимостей. Мы фиксируем «allow-list» библиотек, включаем shared-зависимости, измеряем вклад каждого модуля в LCP/INP. Критичные части — стримим, тяжёлые виджеты — лениво. Любой модуль обязан укладываться в бюджет по весу и времени интерактива, иначе не попадает в релиз.

8) Релизы и эксплуатация

Отдельные пайплайны CI/CD, version pinning и «канарейки» на уровне маршрутов. Дашборды по модулям: ошибки, Web Vitals, вклад в конверсию. Инциденты — локализованные: модуль можно откатить/запинить версию без остановки всего приложения. В договорённостях — SLA по фиксам, контракты поддержки и «вредные» зависимости.

9) Анти-паттерны

• «Разрезать» монолит на кусочки без доменных границ — только боль и накладные.
• Каждый модуль со своей UI-библиотекой — дубли кода и нестыковки дизайна.
• MF без контрактов и версий — ломкие интеграции и хаос в релизах.
• Общий глобальный стор для всех модулей — утечка инкапсуляции.
• Сложная персонализация в каждом модуле — лучше централизовать в платформе.

Итог: microfrontends — это организационный инструмент, который требует строгих границ, контрактов и платформы. Мы собираем их там, где это окупается: независимые команды, сложный продукт, разные циклы релизов. В остальных случаях лучше модульный монолит. Готовы оценить и предложить план миграции/внедрения под ваш продукт.