теория
После лестницы разговора остаётся вопрос: а что зонам вообще можно делить? Три легальных общих актива — и у каждого свой режим владения.
Дизайн-система. Единственный общий код, и живёт он как версионируемый пакет: кнопки, таблицы, токены цветов и отступов — с владельцем, версиями и правилами совместимости. Два правила эксплуатации, оба выстраданы индустрией. Первое: извлекать после того, как паттерн проявился, — компонент, придуманный «на вырост» для всех, обычно не подходит никому; компонент, скопированный дважды и попрошенный третьей командой, — готовый кандидат. Второе: никакой доменной логики — таблица «умеет сортировать колонки» — да; таблица «знает, как показывать тендеры B2B» — нет: доменное знание в общем пакете связывает команды сильнее любого стора, потому что заставляет релизить дизайн-систему при изменении бизнес-правил.
Сессия и права. Логин один на терминал, владеет им оболочка. Зона спрашивает «кто пользователь и что ему можно» через явный интерфейс — и не хранит ни токенов, ни паролей: токены живут в серверном слое, браузеру достаётся кука. Правам, кстати, зона верит только для отрисовки (показать ли кнопку) — настоящая проверка всегда на API, это end-to-end argument из двадцать первого модуля, у него нет исключений и во фронтенде.
Схемы событий и параметров. Реестр контрактов — тот же, что у бэкенда, и правила те же: только добавляй, терпимый читатель, проверка совместимости в CI. Контрактный тест зоны-издателя фиксирует схему («ряд выбран»: id, название, регион), контрактный тест слушателя — его ожидания; несовместимое изменение роняет сборку издателя. Дешёвая механика — и целый класс инцидентов «переименовали поле, узнали в проде» вымирает, как вымер после десятого модуля на бэкенде.
Всё остальное — не общее. И это не аскеза, а определение хорошей нарезки: чем короче список общего, тем честнее проведены границы.