Frontend-архитектура

Для чего модуль

Научиться проектировать frontend-архитектуру, которая выдерживает рост продукта, команды и требований к качеству.

Результат после прохождения

1. Вы умеете строить модульные границы и управлять зависимостями.
2. Вы снижаете архитектурный риск через ownership и правила взаимодействия модулей.
3. Вы можете эволюционировать legacy-зоны без остановки разработки.
4. Вы защищаете архитектурные решения через метрики и эксплуатационные последствия.

Термины и аббревиатуры

Термин	Коротко
Coupling	Связанность модулей
Cohesion	Целостность модуля
Ownership	Ответственный за зону
Dependency map	Карта зависимостей
Migration plan	План перехода

Фокус по грейдам

1. Junior: понимать базовые механики и объяснять их простыми примерами.
2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем

1. Возьмите один проблемный участок текущего frontend-кода.
2. На каждом уроке фиксируйте: текущая проблема -> целевая архитектура -> план перехода.
3. После каждого урока обновляйте dependency map и ADR.

Программа модуля

Урок 1. Модульность и слои

Цель: разделить систему на зоны ответственности с минимальной связанностью.

Базовые архитектурные слои

1. UI/presentation.
2. Domain/use-cases.
3. Data/integration.
4. Shared/platform.

Принципы модульности

1. Высокая cohesion внутри модуля.
2. Низкая coupling между модулями.
3. Явные public API модуля, скрытые внутренности.

Где ломается в проде

1. Shared слой превращается в «свалку» зависимостей.
2. Модули импортируют внутренности друг друга.
3. Нет правил направления зависимостей.

Мини-задача (обязательная)

Сделайте dependency map одного крупного флоу и выделите 3 нарушения модульных границ с планом исправления.

Что спросит интервьюер: как понять, что модульная архитектура «работает», а не только красиво нарисована.

Критерий готовности по уроку: вы можете показать архитектурную карту системы и объяснить, где сейчас риск связанности.

Урок 2. Ownership и процессы

Цель: привязать архитектуру к ответственности команды.

Ownership model

1. У каждого модуля есть владелец.
2. Ясные правила изменений cross-module.
3. SLA реакции на инциденты и архитектурные регрессии.

Архитектурные quality gates

1. PR-check для границ модулей.
2. ADR для значимых изменений.
3. Автоматические проверки зависимостей (где возможно).

Где ломается в проде

1. «Общий код» без владельца.
2. Критичные решения принимаются устно и не документируются.
3. Инциденты повторяются, потому что ownership не определен.

Мини-задача (обязательная)

Опишите ownership-matrix для 5 ключевых модулей: owner, reviewer, SLA, эскалация.

Что спросит интервьюер: как вы распределяете ответственность за архитектурные зоны.

Критерий готовности по уроку: вы можете превратить архитектуру из схемы в рабочую операционную модель команды.

Урок 3. Архитектурная эволюция

Цель: менять архитектуру постепенно и безопасно.

Подход к миграции

1. Выделяем наиболее рискованную зону.
2. Планируем этапы с checkpoints.
3. Оставляем rollback-вариант на каждом этапе.

Измерение прогресса

1. Снижение cross-module связей.
2. Снижение числа архитектурных нарушений.
3. Влияние на delivery (lead time, defect rate).

Где ломается в проде

1. Попытка «переписать всё» вместо локальных шагов.
2. Нет критериев завершения этапа.
3. Команда теряет скорость из-за неограниченного scope миграции.

Мини-задача (обязательная)

Составьте план архитектурной эволюции на 6 недель для одного legacy-модуля: этапы, риски, метрики, rollback.

Что спросит интервьюер: как вы эволюционируете архитектуру без остановки бизнес-фич.

Критерий готовности по уроку: вы можете показать реалистичный план изменений с управлением риском и влиянием на delivery.

Урок 4. Практика принятия решений

Цель: выстраивать архитектурный диалог на языке компромиссов и последствий.

Decision record

Для каждого решения фиксируйте:

1. Контекст и проблему.
2. Альтернативы.
3. Выбор и rationale.
4. Риски и mitigation.
5. Метрики проверки.

Работа с возражениями

1. «Слишком сложно» -> показываем cost of current complexity.
2. «Долго» -> этапность и quick wins.
3. «Можно потом» -> риск накопления техдолга и стоимость откладывания.

Мини-задача (обязательная)

Подготовьте мини-ADR на одно спорное решение и проведите архитектурную защиту (3 ожидаемых возражения + ответы).

Что спросит интервьюер: как вы защищаете архитектурный выбор, если команда не согласна.

Критерий готовности по уроку: вы ведете архитектурную дискуссию структурно и предметно, без «религиозных» аргументов.

Практика

1. Boundary map и dependency violations

Связка: Senior q-1, Senior q-2, Senior q-18.

Что сделать:

1. Выберите 5 доменов продукта: например catalog, checkout, profile, billing, shared-ui.
2. Заполните architecture boundary map: domain -> owner -> public API -> allowed dependencies -> forbidden dependencies -> validation.
3. Составьте violation register: violation -> impact -> current workaround -> target boundary -> first safe fix.

Артефакт: boundary map + dependency violation register.

Критерий готовности: вы можете показать, какая связь реально опасна, кто владелец boundary и какой guardrail предотвращает повтор.

2. Ownership и platform governance

Связка: Senior q-8, Senior q-16, Playbook q-7.

Что сделать:

1. Подготовьте ownership matrix для shared UI, API client, routing, auth/session, analytics и design tokens.
2. Для каждого shared asset укажите owner, consumers, API stability, a11y requirement, versioning, migration path, adoption signal.
3. Добавьте CI/review guard: lint rule, CODEOWNERS, contract checklist или visual/a11y gate.

Артефакт: ownership/governance matrix + one guardrail proposal.

Критерий готовности: вы объясняете architecture ownership как систему принятия решений, а не как список ответственных людей.

3. Six-week migration plan

Связка: Senior q-12, Senior q-18, Senior q-20.

Что сделать:

1. Выберите legacy zone: например checkout state, shared forms, legacy API client или design system modal.
2. Составьте phased migration plan на 6 недель: phase, scope, compatibility, feature flag, validation, rollback, owner.
3. Добавьте metrics: boundary violations, lead time, defect rate, bundle/CWV impact, incident count or support signal.

Артефакт: six-week migration plan + risk register.

Критерий готовности: вы показываете evolution without freeze: маленькие этапы, проверяемые gates и rollback на каждом рискованном шаге.

4. ADR и защита решения

Связка: Senior q-20, Playbook, Interview pattern taxonomy.

Что сделать:

1. Напишите mini-ADR: context, options, decision, trade-offs, risks, validation, owner, revisit condition.
2. Подготовьте 3 возражения: too complex, too slow, can wait.
3. Ответьте на каждое через current cost, phased rollout, measurable signal и rollback/revisit rule.

Артефакт: mini-ADR + objection handling sheet.

Критерий готовности: вы защищаете решение через evidence и trade-offs, а не через личный вкус или авторитет.

Связь с треками и вопросами

1. Architecture boundaries: Senior q-1, Senior q-2, Senior q-18.
2. Governance and quality gates: Senior q-8, Senior q-16, Playbook q-7.
3. Decision leadership: Senior q-12, Senior q-20, Interview pattern taxonomy.
4. Повторение: через 24 часа пересоберите один ADR и boundary map без подсказок.

Критерий готовности

Ready: вы обосновываете архитектуру через constraints, ownership, risk, migration path, guardrails и измеримое влияние на delivery.

Partial: вы видите проблему в архитектуре, но не можете назвать owner, validation gate, rollback или metric of success.

Not ready: вы предлагаете "переписать нормально" без boundary map, phased migration и decision record.

Артефакты после модуля

1. Architecture boundary map.
2. Dependency violation register.
3. Ownership/governance matrix.
4. Six-week migration plan + risk register.
5. Mini-ADR + objection handling sheet.

Куда дальше

1. Frontend System Design
2. Тестирование frontend
3. Frontend-архитектура