теория
Рамка, которую Иван вывел на доску, известна как decisions framework — четыре решения, которые в микрофронтендах стоит принять до первой строчки кода, потому что менять их потом — миграция.
1. Как нарезать. Два лагеря. Вертикально: зона = раздел = команда, пользовательский сценарий не пересекает границу. Горизонтально: несколько микрофронтендов на одной странице от разных команд. Вертикаль — дефолт: она дешевле в координации и понятнее в ответственности. Горизонталь берут осознанно и точечно — когда на одной странице действительно сосуществуют независимые продукты (виджет чата поддержки поверх любого экрана — честный пример).
Лакмус для спорных мест — кросс-фильтрация: если элементы экрана реагируют друг на друга, они принадлежат одной зоне. Резать «живой» дашборд на куски разных команд — значит превратить каждый клик в межкомандный контракт. Это самый дорогой способ получить самый медленный дашборд.
2. Где склеивать. Три семьи, о них — следующее решение: в сборке, на сервере, в браузере.
3. Кто владеет адресом. URL — это публичный контракт терминала: закладки клиентов, ссылки из писем, «поделиться». Верхний уровень адреса («/series», «/forecasts», «/b2b») принадлежит оболочке — она по нему решает, какую зону грузить; всё, что глубже, — внутреннее дело зоны. Переезд экрана между зонами — смена публичного адреса, со всеми редиректами и болью: ещё одна причина резать по устоявшимся швам.
4. Как разговаривают. Самое минное поле — весь следующий модуль.
Заметь, что три из этих решений — та же тройка вопросов, что при выделении Платежей во втором акте: где граница, как общаемся, кто чем владеет. Новое здесь — четвёртое, композиция: зоны надо ещё и склеить на одном экране. Изменился и рантайм: вместо датацентра — браузер клиента, где нет ни оркестратора, ни ретраев инфраструктуры — только один поток, один экран и терпение пользователя.