Решение о декомпозиции фронтенда чаще всего ломается не на технологии, а на неверном моменте перехода. Команды либо слишком рано прыгают в micro-frontends из-за моды на независимые релизы, либо слишком долго держат один SPA, пока coordination cost не становится главной скоростью команды.
Эта глава полезна тем, что ставит рядом modular monolith и micro-frontends как этапы зрелости, а не как взаимоисключающие лагеря. Она помогает обсуждать доменные границы, release cadence, степень автономии команд и цену runtime integration в одной рамке принятия решения.
Для архитектурных review этот материал особенно ценен, потому что не романтизирует декомпозицию: он заставляет считать integration tax, governance overhead и влияние на UX-consistency до того, как организационная проблема будет замаскирована под якобы техническое решение.
Практическая польза главы
Практика проектирования
Переводите знания о выборе между modular monolith и micro-frontends с учетом командного масштаба в конкретные решения по composition, владению (ownership) и runtime-поведению клиентской системы.
Качество решений
Оценивайте архитектуру по измеримым эффектам: скорость delivery, стабильность UI, наблюдаемость, цена изменений и эксплуатационные риски.
Аргументация на интервью
Стройте ответ как цепочку problem -> constraints -> architecture -> компромиссы (trade-offs) -> migration path, с явной аргументацией frontend-выбора.
Формулировка компромиссов
Фиксируйте компромиссы вокруг выборе между modular monolith и micro-frontends с учетом командного масштаба: масштаб команды, технический долг, performance budget и долгосрочная поддержка.
Контекст
Архитектура frontend-приложения
Разговор о micro-frontends полезен только после того, как modular monolith уже описан через реальные boundaries и ownership.
Большинство команд выбирают micro-frontends слишком рано. На практике сначала стоит ответить на более приземленный вопрос: может ли modular frontend уже решить проблемы scale, ownership и release coordination внутри одного приложения.
Если нет, тогда micro-frontends становятся не модным термином, а реальным ответом на bottleneck командной структуры и слишком большой blast radius одного runtime.
Что сравниваем на самом деле
Модульный frontend (modular monolith)
Один deployable artifact, единый runtime, общие platform defaults и четкие доменные модули внутри репозитория. Часто это лучший следующий шаг после хаотичного SPA.
Micro-frontends
Несколько independently released domains с явными runtime contracts, shell orchestration и повышенным integration tax. Становятся оправданными, когда coordination cost одного приложения действительно стал bottleneck.
Главный вопрос не про технологию, а про ownership
Если командам не нужны независимые release cycles и отдельные contract boundaries, micro-frontends легко оказываются дорогим ответом на еще не существующий организационный вопрос.
Migration path важнее final pattern name
В реальности полезно думать о modular monolith как о дисциплине, которая либо уже достаточна, либо подготавливает продукт к selective micro-frontend split без big-bang миграции.
Сигналы для решения
Командный scale
Сколько команд одновременно трогают один и тот же runtime, насколько часто они конфликтуют по release cadence и нужен ли им реальный operational independence.
Blast radius и platform governance
Можно ли удерживать качество, performance budgets и UX consistency внутри одного приложения, или shared coordination уже стала слишком дорогой.
Runtime integration tax
Micro-frontends покупают автономию ценой orchestration, contract tests, telemetry stitching, shared auth/routing и проблем с dependency duplication.
Migration realism
Есть ли пошаговый путь от текущего modular frontend к selective decomposition, или команда фактически планирует risky rewrite под новое слово в архитектурной моде.
Рекомендуемый migration path
- Сначала навести порядок внутри modular monolith: ownership, import rules, public entrypoints, shared kernel и route boundaries.
- Измерить coordination pain: число cross-team release blockers, shared bottlenecks и частоту конфликтов по runtime.
- Выделять в micro-frontend только те домены, которым действительно нужен независимый deploy и отдельный operational lifecycle.
- Сохранять общий platform contract: auth, navigation, telemetry, design tokens и error handling остаются управляемыми централизованно.
Практическая эвристика
Если продукт все еще не умеет держать чистые модульные границы внутри одного приложения, переносить хаос в micro-frontends почти всегда дороже, чем сначала выстроить modular monolith discipline.
Micro-frontends покупают организационную автономию. Если основной bottleneck еще не в coordination cost команд, а в слабых boundaries и shared chaos, modular frontend чаще дает лучшее соотношение пользы и сложности.
Связанные главы
- Архитектура frontend-приложения: app shell, feature modules и shared kernel - дает modular monolith baseline, без которого micro-frontends почти всегда оказываются преждевременными.
- Building Micro-Frontends - расширяет decision framework практиками доменной декомпозиции и migration path от монолита.
- Micro Frontends in Action - показывает прикладные integration patterns и цену runtime composition на практике.
- The Art of Micro Frontends - добавляет enterprise maturity: governance, orchestration и platform DX для большого числа модулей.
- Monolith to Microservices - полезна как общая migration discipline: сначала boundaries и strangler path, потом более дорогая декомпозиция.