Архитектура фронтенд-приложения становится важной в тот момент, когда кодовая база уже не помещается в голове одной команды и любое изменение начинает цеплять маршрутизацию, общие утилиты и соседние функции. Именно здесь нужны оболочка приложения, функциональные модули и жёсткие правила о том, что можно считать общим ядром, а что должно оставаться внутри домена.
Практическая ценность главы в том, что она помогает не смешивать пользовательский сценарий и технический каркас. Хорошая модульность во фронтенде ускоряет поставку изменений не потому, что папки стали красивее, а потому что зоны ответственности, границы импортов и публичные API модулей становятся предсказуемыми.
Для архитектурного ревью это удобная точка входа в разговор о модульном монолите во фронтенде: как держать оболочку тонкой, как не раздувать общий слой и как эволюционировать приложение без раннего перехода к микрофронтендам.
Практическая польза главы
Практика проектирования
Переводите знания о границах фронтенд-приложения в решения по оболочке приложения, функциональным модулям, общему ядру и направлению импортов.
Качество решений
Оценивайте архитектуру по независимости изменений, прозрачности зависимостей, скорости загрузки экранов и понятности публичных API модулей.
Аргументация на интервью
Стройте ответ как цепочку: доменные границы, общий каркас, правила импортов, источник истины и путь эволюции без преждевременных микрофронтендов.
Формулировка компромиссов
Фиксируйте цену общего ядра: удобство переиспользования, радиус влияния изменений, владение модулями и долгосрочную поддержку платформенного слоя.
Контекст
Зачем нужна архитектура фронтенда
Эта глава переводит обзорную рамку фронтенд-архитектуры в структуру реального приложения: оболочку, функциональные модули и общее ядро.
В сложном фронтенд-продукте архитектура приложения определяет не только структуру кода, но и то, насколько независимо двигаются команды, как быстро загружаются экраны и где живут публичные контракты между частями интерфейса.
Хорошее правило: сначала проектировать границы модулей, а уже потом спорить о библиотеке состояния или паттерне фреймворка. Именно через границы становится видно, что действительно общее, а что просто ещё не разложено по доменам.
В этой главе рассматривается через , , , , , правила зависимостей, публичные точки входа, и путь к без преждевременного усложнения.
Архитектурный каркас
Оболочка приложения отвечает за каркас, а не за бизнес-логику
держит навигацию, общий каркас экранов, , подключение телеметрии и точки интеграции платформы. Бизнес-сценарии не должны превращать её в общий монолит.
Функциональные модули совпадают с продуктовыми границами
Каталог, оформление заказа, платежи, редактор или отчётность должны иметь собственные экраны, сценарии загрузки данных и внутренние интерфейсные примитивы. Так не тянет соседей через глобальный общий слой.
Общее ядро должно быть маленьким и дорогим в изменении
В попадают , примитивы маршрутизации, базовая сессия, и несколько платформенных утилит. Всё остальное сначала считается локальным для домена.
Публичные контракты важнее удобных внутренних импортов
У каждого модуля должны быть , и понятные правила . Иначе приложение быстро становится связанным графом случайных зависимостей.
Связано
Стратегии декомпозиции
Фронтенд-приложение масштабируется лучше, когда модульные границы совпадают с продуктовыми контекстами.
Правила границ
Импорты идут только вниз по архитектурному контуру
может зависеть от , но не от соседнего модуля напрямую. Сценарии между доменами проходят через публичный контракт или слой оркестрации.
Интерфейсные компоненты делятся на локальные и платформенные примитивы
Кнопка, каркас модального окна и типографика на базе токенов живут во . Доменные виджеты вроде таблицы цен или панели документа не должны утекать в общее ядро раньше времени.
Маршрутизация — часть архитектуры, а не только удобство разработки
должно отражать зоны ответственности и . Вложенные каркасы и загрузчики не должны случайно подтягивать всю .
Критические сквозные задачи подключаются одинаково
Телеметрия, , и должны иметь единый , чтобы отладка и поэтапный запуск не зависели от локального стиля команды.
Операционная модель команды
- Каждый имеет команду-владельца, и правила вывода старых контрактов из эксплуатации.
- проходит более строгий пересмотр, чем локальный код домена, потому что его существенно выше.
- Архитектурные зависимости фиксируются в или , а не в устных договорённостях.
- Рефакторинг начинается с упрощения , а не с преждевременного перехода к .
Практический критерий качества
Независимые изменения
Новая функциональность добавляется внутри домена без каскада правок по соседним модулям и .
Прозрачные зависимости
По и дереву маршрутов понятно, где живёт и кто владеет каждой публичной точкой входа.
Контролируемое общее ядро
Общий слой остаётся маленьким, версионируемым и редко меняющимся местом, а не свалкой для всего, что однажды оказалось переиспользуемым.
Связанные главы
- Зачем нужна архитектура фронтенда - даёт карту всего фронтенд-трека и объясняет, почему влияют на скорость поставки изменений.
- Frontend Architecture for Design Systems - добавляет платформенную перспективу: , архитектурное управление и операционную модель общего слоя.
- Слой данных во фронтенде: REST, GraphQL, BFF и оркестрация - продолжает тему границ на стыке функциональных модулей и агрегации данных на серверной стороне.
- Состояние и кэш во фронтенд-приложении - показывает, как архитектурные границы влияют на и инвалидацию кэша.
- Модульный фронтенд или микрофронтенды - помогает понять, когда уже достаточно, а когда нужны более жёсткие командные границы.
- Стратегии декомпозиции - даёт общий архитектурный контекст для , связанности и эволюции модульных границ.