Роль и практика архитектора программного обеспечения
Модель и масштаб — Основы БД, опорные темы, проектирование БД, пакетная работа. Карта — о разделе.
Слово "архитектор" в вакансиях встречается часто — и почти всегда означает разное. В одной компании это senior-разработчик с правом veto на merge, в другой — человек, который рисует схемы для заказчика и почти не пишет код. В этой статье — рабочее определение роли в продуктовой и корпоративной разработке: что от вас ждут на практике, какие слова вокруг роли означают и как не перепутать архитектора с соседними ролями.
Технические темы (стили, NFR, микросервисы) — в оглавлении раздела.
Здесь — роль, ответственность и артефакты.
Углублённая практика — в Практика архитектурного проектирования.
С чего начать, если вы новичок
Архитектура программного обеспечения — это про то, из каких крупных частей состоит система, как они связаны и какие правила действуют при изменениях. Это уровень выше отдельного класса или эндпоинта — вы думаете о сервисах, базах, очередях, границах команд и о том, что будет больно менять через год.
Архитектор — специалист, который помогает команде принять и удержать такие решения — согласовать с бизнесом, зафиксировать в документах, проверить при внедрении и скорректировать по факту эксплуатации. Он может писать код так же, как остальные, но его главная ценность — целостная картина и объяснимые компромиссы, а не количество закрытых задач в спринте.
Если вы только вышли из курсов или джун-позиции, полезно держать в голове три вопроса к любому "архитектурному" совету:
- Какую проблему это решает (нагрузка, сроки, безопасность, несколько команд)?
- Чем заплатим (сложность, стоимость, время разработки)?
- Как поймём, что решение сработало (метрики, инциденты, ADR)?
Что делает архитектор (одним абзацем и по пунктам)
Архитектор программного обеспечения формулирует и удерживает структурные решения — границы подсистем, способы интеграции, стратегию данных, соответствие нефункциональным требованиям (NFR) и правила эволюции системы. Он отвечает за последствия выбора: что будет дорого менять через год и что сломается при росте нагрузки или команды.
На практике это выглядит так:
| Задача | Простыми словами | Пример |
|---|---|---|
| Границы системы | Где заканчивается "наш" код и начинается чужой | Заказы — наш сервис, списание денег — банк или платёжный шлюз |
| Интеграция | Как части обмениваются данными | REST, очередь, файл раз в ночь |
| Данные | Кто владелец таблицы/сущности | Остатки на складе меняет только Inventory |
| NFR | "Как хорошо" работает система | p95 ≤ 400 мс, доступность 99.9% |
| Эволюция | Как безопасно менять старое | Strangler вокруг легаси-монолита |
Хороший архитектор умеет:
- видеть систему целиком и объяснять её простым языком;
- сравнивать варианты с явными компромиссами, а не опираться на моду ("все переходят на Kubernetes");
- вовлекать разработчиков и аналитиков, а не спускать схему сверху;
- фиксировать решения так, чтобы через полгода их понял новый человек.
Мини-глоссарий терминов из статьи
| Термин | Что это значит для новичка |
|---|---|
| NFR (нефункциональные требования) | Требования к качеству: скорость, надёжность, безопасность, стоимость. Подробнее — проектирование под NFR. |
| ADR (Architecture Decision Record) | Короткая запись: какую проблему решали, какие варианты смотрели, что выбрали и почему. |
| C4 | Набор из четырёх уровней схем: контекст → контейнеры → компоненты → код. На старте хватает первых двух. Подробнее — основы диаграмм. |
| Bounded context | Часть предметной области со своим языком и правилами ("заказ" в магазине и "договор" в биллинге — разные смыслы). См. доменную модель. |
| Контракт API | Описание формата запросов/ответов (часто OpenAPI), по которому команды договариваются без чтения всего кода. |
| SLO / RTO / RPO | Цели по надёжности: сколько можно "лежать" (RTO), сколько данных можно потерять (RPO), целевой уровень сервиса (SLO). |
| Spike | Короткий эксперимент в коде, чтобы проверить рискованную идею до большого внедрения. |
| ACL (антикоррупционный слой) | Прослойка, которая переводит чужую модель данных в нашу, чтобы легаси не "заразило" новый код. |
Чем архитектор отличается от соседних ролей
В маленькой команде один человек совмещает несколько шапок — это нормально. Важно понимать фокус каждой роли, чтобы в споре было ясно, кто принимает решение.
| Роль | Фокус | Типичное отличие от архитектора |
|---|---|---|
| Разработчик | Реализация задач в рамках согласованной структуры | Может не участвовать в выборе стиля развёртывания всего портфеля |
| Техлид / Team Lead | Команда, процесс, качество кода в своей зоне | Управляет людьми и спринтом; архитектура одного продукта или стрима |
| Аналитик | Требования, процессы, согласование с бизнесом | Меньше ответственности за технологический стек и эксплуатацию |
| Enterprise-архитектор | Ландшафт организации, стандарты, портфель систем | Шире одного приложения; меньше строк кода |
Техлид часто путают с архитектором. Упрощённо: техлид отвечает, чтобы команда доставляла фичи с приемлемым качеством кода и процессом; архитектор — чтобы система в целом оставалась согласованной при росте и смене людей. Один человек может быть и техлидом, и архитектором на продукте из 5–8 человек.
Проблема начинается, когда нет ясности, кто принимает спорное архитектурное решение: тогда его принимает самый громкий участник совещания. Явная фиксация в ADR снимает часть таких конфликтов.
Виды архитекторов
Карьерные треки не обязаны вести "наверх" в enterprise. Многие сильные специалисты всю жизнь остаются solution-архитекторами глубокого домена (финтех, госсектор, телеком).
| Тип | Зона ответственности | Откуда обычно приходят |
|---|---|---|
| Solution / application architect | Один продукт: модули, API, БД, деплой | Senior-разработчик, аналитик с техническим бэкграундом |
| Integration architect | Стыки систем, шины, контракты, миграции между legacy и новым | Разработчик интеграций, ESB/Middleware |
| Infrastructure / cloud architect | Сеть, кластеры, IAM, стоимость облака | DevOps, SRE, системный администратор |
| Enterprise architect | Карта приложений, принципы, governance, регуляторика | Меньше кода, больше стандартов и портфеля |
Артефакты — что остаётся после работы архитектора
Артефакт — любой результат работы, который переживает совещание — схема, документ, контракт, запись решения. Без артефактов знание живёт в головах двух людей и исчезает при увольнении.
Не обязательно десятки PDF. Минимальный набор, который реально помогает команде:
- Контекст системы (C4 Level 1) — кто пользователи и внешние системы. Одна страница "кто с кем говорит".
- Контейнеры (C4 Level 2) — сервисы, БД, очереди, протоколы. Ответ на вопрос "из чего состоит наше приложение в проде".
- Ключевые сценарии — sequence-диаграммы для оплаты, регистрации, синхронизации с legacy: порядок вызовов при успехе и при ошибке.
- NFR-таблица — измеримые цели (latency, availability, RTO/RPO, безопасность). См. Проектирование под нефункциональные требования.
- ADR — короткие записи "проблема → варианты → решение → последствия".
- Контракты — OpenAPI / AsyncAPI / protobuf там, где есть интеграции.
Jira хранит задачи ("сделать эндпоинт", "поднять Kafka").
ADR хранит причину — почему выбрали Kafka, а не RabbitMQ, и что от этого ожидаем.
Через год никто не вспомнит контекст спора, если он остался только в комментариях к тикету.
Подробнее — в Основах проектирования и Документации как инструменте.
Как начать с нуля: возьмите один спорный выбор последнего месяца (брокер, БД, монолит или выделение сервиса) и оформите ADR на одну страницу. Добавьте одну схему контекста C4. Этого уже достаточно, чтобы команда говорила на одном языке.
Навыки — технические и "мягкие" (оба обязательны)
Технические
- Стили развёртывания: монолит, модульный монолит, микросервисы, события — и умение отложить усложнение, пока NFR и организация этого не требуют.
- Моделирование домена: bounded context, агрегаты, контракты между контекстами (Доменная модель).
- Распределённые системы: согласованность, идемпотентность, доставка сообщений (распределённые системы).
- Безопасность на уровне архитектуры: зоны доверия, threat modeling — стык с ИБ и Threat modeling.
- Эксплуатация: метрики, SLO, поведение при падении узла — стык с DevOps.
Коммуникация и процесс
- Фасилитация workshop’ов (Event Storming, архитектурные сессии на 45–90 минут) — вы задаёте вопросы и фиксируете результат, а не монологируете час.
- Отказ или "позже" с аргументами по риску и стоимости, а не по статусу в должности.
- Переговоры с бизнесом: перевод NFR на язык денег и сроков ("99.99% стоит столько-то инфраструктуры").
- Менторинг: архитектура держится, когда её понимают несколько человек в команде.
Типичный рабочий цикл (как это выглядит в проекте)
- Уточнить NFR вместе с аналитиком и ops — до выбора "микросервисов". Иначе вы оптимизируете модную схему, а не продукт.
- Набросать 2–3 варианта (таблица — плюсы, минусы, риски, стоимость). Шаблон — оценка альтернатив.
- Зафиксировать решение в ADR, согласовать с техлидами затронутых команд.
- Описать границы на C4 и контрактах; критичные потоки — sequence.
- Сопровождать внедрение — architecture review в PR, spike’и на рискованных местах.
- Смотреть на прод — инциденты и метрики корректируют архитектуру так же, как баги корректируют код.
Architecture review — короткая встреча (30–45 минут), где автор решения показывает контекст, варианты и риски; участники задают вопросы. Это обучение команды, а не экзамен "угадать правильный ответ".
Три ситуации из практики (разбор по шагам)
"Нужны микросервисы к релизу через два месяца"
Что слышит архитектор: желание "как у больших", часто без учёта зрелости CI/CD, мониторинга и числа команд.
Вопросы, которые стоит задать вслух:
- Сколько независимых команд будет релизить части системы?
- Какие NFR (latency, согласованность, доступность)?
- Есть ли tracing, централизованные логи, автоматические деплои?
Частый рабочий ответ: модульный монолит с чёткими границами модулей и контрактом "как будущий сервис"; резать на отдельные деплои позже — по метрикам связности и по организации. См. модульный монолит, практику.
"Два отдела по-разному называют клиента"
Это сигнал разных bounded context, а не задачи "свести всё в одну таблицу Customer". У отдела продаж "клиент" — контакт и сделка; у биллинга — плательщик и договор. Общая таблица без перевода смыслов приводит к полям "client_type_2" и вечным багам.
Что делать: контекстная карта (кто upstream/downstream), явный антикоррупционный слой на интеграции. См. доменную модель, Event Storming.
"Легаси трогать нельзя, но нужен новый UI"
Классический Strangler Fig (удушение снаружи) — новый фасад принимает трафик, постепенно перенаправляет операции в новый код, старый монолит сужается. Пользователь видит новый интерфейс; ядро меняется по частям. См. Strangler Fig.
Как расти в архитектора осознанно
- Вести минимум один ADR в месяц на своём проекте — даже для маленьких решений (выбор кэша, формат логов).
- Разобрать один продакшен-инцидент с точки зрения границ и NFR: где была слабая связность, где не хватало лимитов или идемпотентности.
- Провести архитектурную сессию с командой (Architecture Kata или разбор реального ТЗ).
- Пройти цепочку в разделе: Основы → NFR → Event Storming → оценка альтернатив → API → микросервисы → итоги.
Карьерные ожидания и мифы про IT — в разделе Карьера в IT.
Краткий чек-лист "я на правильном пути"
- Могу объяснить систему за 10 минут на одной схеме контекста и контейнеров.
- Знаю топ-3 NFR продукта и как они отражены в коде/инфре.
- Есть хотя бы 3 ADR по спорным решениям.
- Разработчики участвуют в проектировании, а не только получают готовую диаграмму.
- После релиза смотрю метрики/инциденты и готов скорректировать границы.
Что архитектор делает в течение недели — приземлённо
Чтобы роль не выглядела абстрактной, вот типичный недельный ритм архитектора в продуктовой команде:
- Понедельник: уточнение NFR и рисков по новым инициативам.
- Вторник: архитектурная сессия по спорному решению, фиксация ADR.
- Среда: ревью критичных PR по границам модулей и контрактам.
- Четверг: анализ продакшен-метрик и инцидентов, корректировка решений.
- Пятница: менторинг команды и обновление схем и документации.
Сигналы зрелой архитектурной роли
- Команда понимает причину решений, а не только их форму.
- Архитектурные документы обновляются вместе с кодом.
- Технический долг виден в backlog и управляется.
- Конфликты на стыках команд решаются через контракты.
Частые ошибки роли
- Уход в "рисование диаграмм" без внедрения и обратной связи.
- Ставка только на технологические тренды без бизнес-контекста.
- Отсутствие критериев успеха для архитектурных инициатив.
- Централизация знаний в одном человеке.
План развития роли на 90 дней
Если вы переходите в архитектурную роль, можно использовать такой маршрут:
- Первые 30 дней — собрать карту системы, NFR и список рисков, наладить формат ADR.
- Дни 31-60 — провести 2-3 архитектурные сессии по критичным узлам, согласовать границы модулей.
- Дни 61-90 — запустить цикл измерений и ревью — метрики, инциденты, корректировка решений.
К концу периода у команды должен появиться устойчивый ритм архитектурной работы, который живёт вместе с поставкой фич.
Связанные статьи для роста: Практика архитектурного проектирования, Системный подход, Паттерны проектирования, Коммуникация и общение.
Дальше — Практика архитектурного проектирования и оглавление раздела.
В подборках
Статья входит в тематические подборки и блок "С чего начать?" на главной. Соседние шаги того же маршрута:
Техлид — Проектирование и архитектура — о разделе, Паттерны проектирования — о разделе, Специализации, Проектирование — о разделе, Архитектура выполнения — о разделе, Микросервисы и интеграция — о разделе.