# Практическая рамка разбора архитектуры ПО

Архитектурный разбор, который не может назвать решение, которое поддерживает, — это экскурсия. Я пользуюсь коротким набором вопросов, на которых можно провалиться. Если система проходит — спорим о вкусе. Если нет — есть последовательность. Это список, который я реально несу в репозиторий.

## 1. Ограничение

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

## 2. Форма изменений

Где концентрируются diff? Если каждая фича трогает один модуль, нарезка на сервисы клонирует узкое место. Сначала разложите модуль. Границы сервисов — для независимо меняющихся причин, не для оргсхемы, которую вам хотелось бы иметь.

## 3. Контракты

Границы типизированы, версионированы и кому-то принадлежат? Неявный JSON между тремя командами — инцидент с лишними шагами. Это ещё жёстче, когда на пути модель: вероятностному выходу схемы и пути отказа нужны больше, чем человеческим полезным нагрузкам.

## 4. Отказ

Что будет, когда очередь, провайдер или модель ошибутся или исчезнут? «Пользователь повторит» — не дизайн. Идемпотентность, таймауты, отравление и человеческий путь — да. Читаю задачи и консьюмеры, прежде чем верить диаграмме счастливого пути.

## 5. Эксплуатация

Может ли нормальный новый инженер за полдень найти путь от HTTP-запроса до строки? Если ответ зависит от одного человека, у вас bus factor, а не архитектура. Логи и трассы, которые не отвечают «что случилось с этим id», — декорация.

## 6. Команда

Этот дизайн выживет, если платформенная команда, которой у вас нет, так и не появится? Рекомендовать Kubernetes, mesh и озеро данных команде из шести человек — халатность. Порекомендую самую простую форму, которая выдерживает ограничение и численность.

## Как пишу выход

Памятка решения: контекст, что удалось проверить, варианты с компромиссами, рекомендация и то, чего мы сознательно не делаем. Диаграммы только там, где меняют вызов. C4 на 40 коробок, которые никто не сопоставит с путём в репозитории, хуже, чем никакой диаграммы.
Если честный результат — «оставайтесь и потратьте бюджет рерайта на тесты и модуль, который реально болит», я так и напишу. Разбор — не прелюдия к продаже перестройки.

## Коротко
- Назовите ограничение, иначе разбираете вкус.
- Идите за концентрацией изменений, не за оргсхемой.
- Отказ и эксплуатация — первого класса, в том числе для ИИ.
- Подгоняйте дизайн под команду, которая есть.
- Пишите решение, не постер.

Canonical: https://ihar-ivaniuk.com/ru/insights/architecture-review-framework
Author: Игорь Иванюк