Архитектура ПО
Практическая рамка разбора архитектуры ПО
Архитектурный разбор, который не может назвать решение, которое поддерживает, — это экскурсия. Я пользуюсь коротким набором вопросов, на которых можно провалиться. Если система проходит — спорим о вкусе. Если нет — есть последовательность. Это список, который я реально несу в репозиторий.
1. Ограничение
Какой отказ дорог: срок поставки, инциденты, инфраструктура, корректность или дата, которую нельзя сдвинуть? Если никто не отвечает, разбор станет спором о стеке. Остановлюсь и зафиксирую ограничение письменно, прежде чем рисовать квадраты.
2. Форма изменений
Где концентрируются diff? Если каждая фича трогает один модуль, нарезка на сервисы клонирует узкое место. Сначала разложите модуль. Границы сервисов — для независимо меняющихся причин, не для оргсхемы, которую вам хотелось бы иметь.
3. Контракты
Границы типизированы, версионированы и кому-то принадлежат? Неявный JSON между тремя командами — инцидент с лишними шагами. Это ещё жёстче, когда на пути модель: вероятностному выходу схемы и пути отказа нужны больше, чем человеческим полезным нагрузкам.
4. Отказ
Что будет, когда очередь, провайдер или модель ошибутся или исчезнут? «Пользователь повторит» — не дизайн. Идемпотентность, таймауты, отравление и человеческий путь — да. Читаю задачи и консьюмеры, прежде чем верить диаграмме счастливого пути.
5. Эксплуатация
Может ли нормальный новый инженер за полдень найти путь от HTTP-запроса до строки? Если ответ зависит от одного человека, у вас bus factor, а не архитектура. Логи и трассы, которые не отвечают «что случилось с этим id», — декорация.
6. Команда
Этот дизайн выживет, если платформенная команда, которой у вас нет, так и не появится? Рекомендовать Kubernetes, mesh и озеро данных команде из шести человек — халатность. Порекомендую самую простую форму, которая выдерживает ограничение и численность.
Как пишу выход
Памятка решения: контекст, что удалось проверить, варианты с компромиссами, рекомендация и то, чего мы сознательно не делаем. Диаграммы только там, где меняют вызов. C4 на 40 коробок, которые никто не сопоставит с путём в репозитории, хуже, чем никакой диаграммы.
Если честный результат — «оставайтесь и потратьте бюджет рерайта на тесты и модуль, который реально болит», я так и напишу. Разбор — не прелюдия к продаже перестройки.
Коротко
- Назовите ограничение, иначе разбираете вкус.
- Идите за концентрацией изменений, не за оргсхемой.
- Отказ и эксплуатация — первого класса, в том числе для ИИ.
- Подгоняйте дизайн под команду, которая есть.
- Пишите решение, не постер.