Архитектура frontend-приложения становится важной в тот момент, когда кодовая база уже не помещается в голове одной команды и любое изменение начинает цеплять routing, shared utilities и соседние фичи. Именно здесь нужны app shell, feature modules и жесткие правила о том, что можно считать shared kernel, а что должно оставаться внутри домена.
Практическая ценность главы в том, что она помогает не смешивать product flow и технический каркас. Хорошая модульность во фронтенде ускоряет delivery не потому, что папки стали красивее, а потому что ownership, границы импортов и публичные API модулей становятся предсказуемыми.
Для design review это удобная точка входа в разговор о modular monolith frontend: как держать shell тонким, как не раздувать shared-слой и как эволюционировать приложение без раннего прыжка в micro-frontends.
Практическая польза главы
Практика проектирования
Переводите знания о границах frontend-приложения, модульности и контролируемом shared kernel в конкретные решения по composition, владению (ownership) и runtime-поведению клиентской системы.
Качество решений
Оценивайте архитектуру по измеримым эффектам: скорость delivery, стабильность UI, наблюдаемость, цена изменений и эксплуатационные риски.
Аргументация на интервью
Стройте ответ как цепочку problem -> constraints -> architecture -> компромиссы (trade-offs) -> migration path, с явной аргументацией frontend-выбора.
Формулировка компромиссов
Фиксируйте компромиссы вокруг границах frontend-приложения, модульности и контролируемом shared kernel: масштаб команды, технический долг, performance budget и долгосрочная поддержка.
Контекст
Зачем нужна архитектура фронтенда
Эта глава переводит обзорный разговор о frontend-архитектуре в структуру реального приложения: shell, modules и shared kernel.
В сложном frontend-продукте архитектура приложения определяет не только структуру кода, но и то, насколько легко командам двигаться независимо, как быстро загружаются экраны и где именно живут публичные контракты между частями интерфейса.
Хорошее правило: сначала проектировать границы модулей, а уже потом спорить про state library или framework pattern. Именно через границы становится видно, что действительно shared, а что просто пока не разложено по доменам.
Архитектурный каркас
App shell отвечает за каркас, а не за бизнес-логику
Shell держит layout, навигацию, identity, telemetry и platform-level hooks. Бизнес-фичи не должны превращать его в shared-монолит.
Feature modules совпадают с bounded contexts
Каталог, checkout, billing, editor или reporting должны иметь собственные экраны, data hooks и внутренние UI-примитивы без постоянного обращения в global shared.
Shared kernel должен быть маленьким и дорогим в изменении
Design tokens, routing primitives, auth session, telemetry adapters и few platform utilities. Все остальное сначала считается локальным для домена.
Публичные контракты важнее удобных внутренних импортов
У каждого модуля должны быть entrypoints, versionable API и понятные ownership-правила, иначе приложение быстро превращается в связанный граф случайных зависимостей.
Связано
Стратегии декомпозиции
Frontend-приложение масштабируется лучше, когда модульные границы совпадают с продуктовыми bounded contexts.
Правила границ
Импорты только вниз по архитектурному контуру
Feature module может зависеть от shared kernel, но не от соседнего feature напрямую. Кросс-доменные сценарии проходят через публичный контракт или orchestration layer.
UI-компоненты делятся на local primitives и platform primitives
Button, modal shell и token-aware typography живут в общей платформе. Доменные widgets вроде pricing table или document toolbar не должны утекать в shared раньше времени.
Маршрутизация - часть архитектуры, а не только DX
Route tree должен отражать ownership и lazy-loading boundaries. Вложенные layouts и loaders не должны случайно тянуть весь runtime каждого модуля.
Критические cross-cutting concerns подключаются одинаково
Telemetry, error boundary, auth guard и feature flag evaluation должны иметь единый integration pattern, чтобы отладка и rollout не зависели от локального стиля команды.
Operating model команды
- Каждый feature-модуль имеет owner-команду, публичный API и правила deprecation.
- Shared kernel проходит review строже, чем локальный код домена, потому что его blast radius существенно выше.
- Архитектурные зависимости фиксируются в ADR или import-policy, а не в устных договоренностях.
- Refactoring начинается с упрощения границ модулей, а не с преждевременной перестройки под micro-frontends.
Практический критерий качества
Независимые изменения
Новая фича добавляется внутри домена без каскада правок по соседним модулям и shared utils.
Прозрачные зависимости
По import graph и route tree понятно, где живет source of truth и кто владеет каждым public entrypoint.
Контролируемый shared kernel
Общий слой остается маленьким, versionable и редким местом изменения, а не свалкой для всего переиспользуемого.
Связанные главы
- Зачем нужна архитектура фронтенда - дает карту всего frontend track и объясняет, почему границы приложения влияют на delivery speed.
- Frontend Architecture for Design Systems - добавляет платформенную перспективу: design system, governance и operating model для shared слоя.
- Data layer во фронтенде: REST, GraphQL, BFF и orchestration - продолжает тему границ на стыке feature-модулей и backend aggregation.
- Состояние и кэш во frontend-приложении - показывает, как архитектурные boundaries влияют на source of truth и invalidation.
- Модульный frontend vs micro-frontends - помогает понять, когда modular monolith уже достаточен, а когда нужны более жесткие командные границы.
- Стратегии декомпозиции - дает общий architectural контекст для bounded contexts, coupling и эволюции модульных границ.