Software Architect · Модуль 01
Архитектор — это не человек, который рисует красивые диаграммы. Это инженер, который отвечает за форму системы и последствия решений во времени.
Роль · ответственность · горизонт мышления
Senior engineer хорошо решает задачи. Архитектор проверяет, правильные ли задачи вообще попали в работу.
Архитектор владеет последствиями
Инженер ставит дверь ровно. Архитектор решает, где в здании вообще должна быть дверь, чтобы через неё не проходил весь складской поток.
Разница между senior engineer и architect не в том, что архитектор знает больше паттернов. Senior обычно отвечает за качество решения внутри понятной задачи: реализовать, упростить, ускорить, покрыть тестами, провести ревью. Архитектор отвечает за то, чтобы сама форма решения выдержала нагрузку времени: новые команды, новые клиенты, рост данных, смену требований, инциденты, аудит, миграции.
Хороший архитектор умеет сказать: «Эта фича выглядит простой, но она меняет модель владения данными» или «Если мы сейчас отдадим этот контракт наружу, то будем поддерживать его годами». Это не торможение разработки. Это защита команды от решений, которые выглядят дешёвыми только в текущем спринте.
Что архитектор держит лично
Капитан не крутит каждый винт корабля, но отвечает за курс, карту, риски и момент, когда нужно менять маршрут.
Архитектор не обязан лично выбирать каждую библиотеку. Но он должен владеть решениями, которые задают траекторию системы: boundaries между подсистемами, модель данных, интеграционные контракты, стратегия tenancy, безопасность, observability, reliability, deployment topology, миграционный путь.
Есть полезное разделение: reversible decisions и irreversible decisions. Обратимые решения можно делегировать агрессивно: конкретный UI-компонент, internal helper, формат лог-сообщения внутри сервиса. Дорого обратимые решения архитектор должен как минимум видеть: выбор базы, external API, ownership данных, split монолита, способ авторизации.
Одна и та же задача может быть инженерной или архитектурной — зависит от последствий.
Пример: добавить комментарии к блогу
На вид это маленькая фича: форма, список, кнопка отправки. Но под ней быстро появляется система прав, модерация, антиспам, хранение, удаление, уведомления.
Инженерный взгляд: сделать endpoint POST /comments, таблицу comments, компонент списка и форму. Архитектурный взгляд добавляет вопросы: комментарии привязаны к slug или к локали поста? Что делать при переименовании slug? Кто может удалять? Что считается source of truth для пользователя? Нужна ли soft delete модель? Как защититься от spam и rate abuse? Как потом добавить owner moderation?
Хорошее архитектурное решение может быть всё ещё простым: одна таблица comments, thread per slug, typed domain errors, rate limiting, owner moderation позже. Но оно уже осознанное.
Антипример: архитектор как главный согласователь
Если все ждут одного человека, чтобы переименовать поле, это не архитектура. Это очередь.
Плохой архитектор превращает себя в bottleneck. Он требует ревью каждого класса, спорит о нейминге локальных переменных и называет это «контролем архитектуры». В итоге команда перестаёт думать сама, а архитектор тонет в мелочах.
Правильная модель другая: архитектор задаёт принципы, границы и quality gates. Команда принимает локальные решения сама, но знает, где начинается зона высокого риска.
- Какие решения в твоей системе дорого откатить? - Кто сейчас владеет моделью данных? - Какие решения команда может принимать без архитектора? - Где архитектор стал bottleneck вместо усилителя?