«Архитектор» в программном проекте — понятие расплывчатое. В одних командах это отдельный человек, в других — тимлид по совместительству, в третьих — старший разработчик, которому «вдобавок» дали эту роль. Но за словом стоит конкретный набор обязанностей, которые в любом случае кто-то несёт.
Разберём их по одной — что это такое, зачем нужно, и что бывает, когда этого нет.
Держать карту системы
Представьте компанию с десятью микросервисами. Через год никто не может с уверенностью ответить: «Кто владеет таблицей пользователей? Какой сервис публикует событие об оплате? Можно ли изменить это поле, не сломав ничего?»
Это значит, что карта системы потеряна. Карта — это не обязательно красивая схема, это ответы на вопросы: кто за что отвечает, кто с кем общается, какие данные где живут.
Архитектор отвечает за то, чтобы карта существовала и не устаревала. Без неё каждое следующее решение принимается вслепую.
Принимать архитектурные решения — и записывать их
Монолит или отдельный сервис? Хранить данные в реляционной базе или аналитическом хранилище? Синхронный вызов или очередь? Это развилки, в которых нет универсально правильного ответа — только «правильный для нашей ситуации».
Обязанность архитектора — не «знать ответ», а провести решение по критериям: какой объём данных ожидается, сколько пользователей, какая команда, каков горизонт. Взвесить, выбрать и записать.
Запись называется ADR (Architecture Decision Record). Это короткий документ: контекст, само решение, альтернативы и причины отказа от них. Через год, когда придёт новый человек и спросит «а почему мы так сделали?» — ответ будет в ADR, а не только в голове одного человека.
Когда решения не записывают, они переоткрываются заново. Команда проводит дискуссию, которую уже проводила год назад, и нередко приходит к другому выводу — не потому что изменилось что-то важное, а потому что никто не помнит, почему выбрали именно тот путь.
Проектировать границы сервисов
Один из самых болезненных вопросов в распределённых системах: где заканчивается один сервис и начинается другой?
Если граница проведена неверно, это расползается во всё: лишние вызовы между сервисами, общие базы данных (что делает сервисы зависимыми), путаница в терминах (в одном сервисе это «клиент», в другом — «покупатель», и никто не уверен, одно ли это и то же).
Архитектор решает, где провести границу — исходя из того, какие данные и процессы меняются вместе, а какие независимо. Это одна из самых дорогих ошибок: неправильная граница обнаруживается поздно и переделывается долго.
Видеть сквозные процессы
Один сервис отвечает за оформление заказа, другой — за склад, третий — за доставку, четвёртый — за уведомления. Но кто отвечает за весь процесс «от нажатия кнопки до посылки у двери»?
Это задача архитектора — видеть процессы, которые пересекают несколько сервисов: где они начинаются, кто что делает на каждом шаге, что происходит при сбое. Если этого нет, каждый сервис знает только про свой кусок, и никто не знает про целое.
Такие процессы нужно описывать явно: кто оркестрирует, как компенсировать ошибку на третьем шаге, когда уведомить пользователя. Без этого сбои становятся неожиданностью.
Оценивать последствия изменений
«Поменяем формат события об оплате» — кого это затронет? Ответ «вроде никого» — начало инцидента.
Архитектор отвечает за то, чтобы такие вопросы имели проверяемый ответ. Для этого нужна та самая карта: зная, кто потребляет событие, можно заранее оценить последствия и принять решение — внести изменение, сделать версионирование или не трогать вовсе.
Без этого изменения выкатываются в продакшн и ломают что-то, о чём никто не подумал. Не потому что разработчики невнимательны — просто без карты невозможно держать в голове все связи большой системы.
Следить за согласованностью
Системы накапливают несоответствия медленно. Один сервис начал называть сущность иначе. Два сервиса объявили себя владельцами одного поля. Спецификации устарели и не соответствуют коду.
По одному случаю это мелочи. Накопившись, они делают карту бесполезной и усложняют работу.
Архитектор периодически проверяет согласованность: терминология единая, владение данными не пересекается, описания актуальны. Это черновая работа, для которой редко находится время, — и поэтому она обычно и не делается, пока не становится слишком больно.
Превращать решения в стандарты
Архитектурное решение, которое нигде не закреплено, живёт два спринта. Договорились, что синхронные вызовы между сервисами — только через отдельный шлюз. Через месяц это правило нарушается, потому что новый разработчик о нём не знал, а старые забыли.
Обязанность архитектора — превращать решения в проверяемые правила: стандарты, соглашения, шаблоны. Правило, которое проверяется при каждом ревью, живёт; правило, которое просто «договорились», нет.
Как устроить такую проверку — отдельная тема: исполняемые инженерные стандарты.
Архитектор vs тимлид vs разработчик
В маленьких командах один человек совмещает несколько ролей. Важно понимать, что обязанности архитектора при этом никуда не деваются — они просто ложатся на кого-то конкретного.
Если в команде нет выделенного архитектора, полезно явно договориться: кто ведёт карту системы, кто документирует решения, кто следит за согласованностью. Когда этого нет, обязанности не выполняются — и со временем накапливаются невидимые проблемы.
Главная характеристика архитектурной работы: её результаты не видны немедленно. Хорошая архитектура не заметна — система просто работает и меняется без боли. Плохая становится видна через год, когда любое изменение требует недели, а не часов.
Коротко
- Архитектор — это набор обязанностей, а не обязательно должность: в небольших командах их берёт тимлид или старший разработчик.
- Карта системы — основа: кто чем владеет, кто с кем общается, где живут данные. Без неё решения принимаются вслепую.
- Архитектурные решения нужно записывать — иначе они переоткрываются заново. Для этого есть ADR.
- Границы сервисов — одна из самых дорогих ошибок проектирования: неверная граница расползается в контракты, данные и организацию.
- Сквозные процессы никто не видит, кроме архитектора — каждый сервис знает только про свой кусок.
- Оценка последствий изменений требует карты: без неё «вроде никого не затронет» — начало инцидента.
- Стандарты работают, только когда они проверяются, а не просто «договорились».
Что почитать дальше
- ADR — как оформлять и хранить архитектурные решения.
- Синхронная и асинхронная коммуникация — одна из типичных развилок, которые решает архитектор.
- Модель C4 — язык диаграмм для карты системы.
- Исполняемые инженерные стандарты — как превратить решения в правила, которые проверяются автоматически.