Межі frontend-системи до microfrontends

Коли frontend стає повільним у розробці, першою підозрою часто є стек. Команда обговорює microfrontends, monorepo, новий state manager або черговий framework. Але технологія рідко виправляє систему, у якій невідомо, де закінчується відповідальність одного модуля і починається відповідальність іншого.

Спочатку потрібні межі. Лише потім — інструмент, який ці межі підтримує.

Симптом: локальна зміна перестала бути локальною

У системи з розмитими межами є впізнавані ознаки:

• зміна checkout вимагає редагувати загальний store, layout і кілька непов’язаних компонентів;
• будь-який модуль може імпортувати внутрішні деталі іншого;
• одна бізнес-сутність має різну форму на сторінці, в API-клієнті та в аналітиці;
• shared-папка росте швидше за продуктові модулі;
• команда боїться видаляти код, бо не бачить усіх його споживачів.

Це не обов’язково проблема розміру codebase. Невеликий застосунок із неконтрольованими залежностями може бути складнішим за великий, але поділений на зрозумілі частини.

Справжня причина: структура описує типи файлів

Папки components, hooks, utils і services відповідають на питання «чим є цей файл?». Вони не відповідають на важливіше питання: «яку частину продукту він обслуговує?»

Через це одна продуктова зміна розсипається по всьому дереву:

components/CheckoutForm.tsx
hooks/useCheckout.ts
services/checkout.ts
utils/formatCheckoutError.ts

Альтернатива — модуль, зібраний навколо відповідальності:

checkout/
  api/
  model/
  ui/
  public.ts

Назви папок самі по собі нічого не гарантують. Різницю створює правило: зовнішні споживачі імпортують лише те, що модуль відкриває через публічний контракт.

Визначте межі трьома питаннями

Для кожної кандидатної області варто відповісти:

1. Яке рішення вона приймає самостійно? Checkout може володіти правилами переходу між кроками, але не політикою авторизації.
2. Якими даними вона володіє? Модуль має одну канонічну модель і перетворює зовнішні дані на межі, а не розносить API-відповідь по всьому UI.
3. Який мінімальний контракт потрібен іншим? Публічний API відкриває сценарії та типи, але приховує внутрішні компоненти, запити й стан.

Якщо відповіді нечіткі, розділення на окремі deployable-застосунки лише зробить нечіткість дорожчою.

Побудуйте карту залежностей до рефакторингу

Не починайте з переміщення файлів. Спочатку запишіть поточні зв’язки між продуктовими областями.

Для кожного зв’язку позначте:

• хто є власником даних;
• хто ініціює дію;
• чи потрібна синхронна відповідь;
• чи є залежність частиною стабільного контракту;
• що станеться, якщо постачальник зміниться або тимчасово недоступний.

Така карта швидко показує цикли. Наприклад, якщо catalog знає про checkout, а checkout імпортує внутрішній state із catalog, команда не має двох модулів — вона має одну систему, випадково розкладену у дві папки.

Закріпіть межі технічно

Домовленість без перевірки поступово зникає. Межу варто зробити видимою в інструментах:

• один публічний entry point на модуль;
• заборонені deep imports;
• правила залежностей у lint або перевірці графа;
• contract-тести для перетворення даних на вході;
• ownership для публічного API модуля;
• короткий ADR для винятків.

Почніть з однієї зміни, яка регулярно болить. Виділіть її область, опишіть контракт, переведіть одного споживача й лише тоді масштабуйте підхід. Великий одномоментний rewrite створить ще одну систему, межі якої команда не встигне перевірити практикою.

Коли microfrontends справді можуть допомогти

Microfrontends стають доречними, коли організаційна незалежність уже існує або свідомо будується:

• різні команди володіють різними продуктовими областями;
• їм потрібні незалежні цикли release;
• публічні контракти достатньо стабільні;
• команда готова платити за узгодження навігації, observability, дизайну, залежностей і версій.

Якщо ж головна проблема — хаотичні імпорти всередині однієї команди, дешевше спочатку створити модульний monolith. Він дозволяє перевірити межі без мережевих, deployment і runtime-компромісів.

Як виміряти результат

«Архітектура стала чистішою» — слабкий критерій. Перевіряйте поведінку системи:

• скільки модулів зачіпає типова продуктова зміна;
• скільки порушень меж знаходить автоматична перевірка;
• чи можна замінити внутрішню реалізацію без змін у споживачах;
• скільки часу новій людині потрібно, щоб знайти власника сценарію;
• як часто pull request блокується через неочікуваний вплив на іншу область.

Мета меж — не намалювати ідеальну діаграму. Мета — зробити вартість зміни передбачуваною. Якщо команда може пояснити власність, контракт і напрям залежності, вибір monorepo, microfrontends або framework стає наслідком системи, а не спробою її замінити.