Роль и практика архитектора программного обеспечения

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору Аналитику Руководителю

Слово «архитектор» в вакансиях встречается часто — и почти всегда означает разное. В одной компании это senior-разработчик с правом veto на merge, в другой — человек, который рисует схемы для заказчика и почти не пишет код. В этой статье — рабочее определение роли в продуктовой и корпоративной разработке: что от вас ждут на практике, какие слова вокруг роли означают и как не перепутать архитектора с соседними ролями.

Связь с разделом

Технические темы (стили, NFR, микросервисы) — в оглавлении раздела. Здесь — роль, ответственность и артефакты. Углублённая практика — в Практика архитектурного проектирования.

---

С чего начать, если вы новичок

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

Архитектор — специалист, который помогает команде принять и удержать такие решения: согласовать с бизнесом, зафиксировать в документах, проверить при внедрении и скорректировать по факту эксплуатации. Он может писать код так же, как остальные, но его главная ценность — целостная картина и объяснимые компромиссы, а не количество закрытых задач в спринте.

Если вы только вышли из курсов или джун-позиции, полезно держать в голове три вопроса к любому «архитектурному» совету:

1. Какую проблему это решает (нагрузка, сроки, безопасность, несколько команд)?
2. Чем заплатим (сложность, стоимость, время разработки)?
3. Как поймём, что решение сработало (метрики, инциденты, 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. Минимальный набор, который реально помогает команде:

1. Контекст системы (C4 Level 1) — кто пользователи и внешние системы. Одна страница «кто с кем говорит».
2. Контейнеры (C4 Level 2) — сервисы, БД, очереди, протоколы. Ответ на вопрос «из чего состоит наше приложение в проде».
3. Ключевые сценарии — sequence-диаграммы для оплаты, регистрации, синхронизации с legacy: порядок вызовов при успехе и при ошибке.
4. NFR-таблица — измеримые цели (latency, availability, RTO/RPO, безопасность). См. 1116.md.
5. ADR — короткие записи «проблема → варианты → решение → последствия».
6. Контракты — OpenAPI / AsyncAPI / protobuf там, где есть интеграции.

Разбор: зачем ADR, если «и так всё в Jira»

Jira хранит задачи («сделать эндпоинт», «поднять Kafka»). ADR хранит причину: почему выбрали Kafka, а не RabbitMQ, и что от этого ожидаем. Через год никто не вспомнит контекст спора, если он остался только в комментариях к тикету. Подробнее — в Основах проектирования и Документации как инструменте.

Как начать с нуля: возьмите один спорный выбор последнего месяца (брокер, БД, монолит или выделение сервиса) и оформите ADR на одну страницу. Добавьте одну схему контекста C4. Этого уже достаточно, чтобы команда говорила на одном языке.

---

Навыки — технические и «мягкие» (оба обязательны)

Технические

• Стили развёртывания: монолит, модульный монолит, микросервисы, события — и умение отложить усложнение, пока NFR и организация этого не требуют.
• Моделирование домена: bounded context, агрегаты, контракты между контекстами (Доменная модель).
• Распределённые системы: согласованность, идемпотентность, доставка сообщений (распределённые системы).
• Безопасность на уровне архитектуры: зоны доверия, threat modeling — стык с ИБ и Threat modeling.
• Эксплуатация: метрики, SLO, поведение при падении узла — стык с DevOps.

Коммуникация и процесс

• Фасилитация workshop’ов (Event Storming, архитектурные сессии на 45–90 минут) — вы задаёте вопросы и фиксируете результат, а не монологируете час.
• Отказ или «позже» с аргументами по риску и стоимости, а не по статусу в должности.
• Переговоры с бизнесом: перевод NFR на язык денег и сроков («99.99% стоит столько-то инфраструктуры»).
• Менторинг: архитектура держится, когда её понимают несколько человек в команде.

---

Типичный рабочий цикл (как это выглядит в проекте)

1. Уточнить NFR вместе с аналитиком и ops — до выбора «микросервисов». Иначе вы оптимизируете модную схему, а не продукт.
2. Набросать 2–3 варианта (таблица: плюсы, минусы, риски, стоимость). Шаблон — оценка альтернатив.
3. Зафиксировать решение в ADR, согласовать с техлидами затронутых команд.
4. Описать границы на C4 и контрактах; критичные потоки — sequence.
5. Сопровождать внедрение — architecture review в PR, spike’и на рискованных местах.
6. Смотреть на прод — инциденты и метрики корректируют архитектуру так же, как баги корректируют код.

Architecture review — короткая встреча (30–45 минут), где автор решения показывает контекст, варианты и риски; участники задают вопросы. Это обучение команды, а не экзамен «угадать правильный ответ».

---

Три ситуации из практики (разбор по шагам)

«Нужны микросервисы к релизу через два месяца»

Что слышит архитектор: желание «как у больших», часто без учёта зрелости CI/CD, мониторинга и числа команд.

Вопросы, которые стоит задать вслух:

• Сколько независимых команд будет релизить части системы?
• Какие NFR (latency, согласованность, доступность)?
• Есть ли tracing, централизованные логи, автоматические деплои?

Частый рабочий ответ: модульный монолит с чёткими границами модулей и контрактом «как будущий сервис»; резать на отдельные деплои позже — по метрикам связности и по организации. См. модульный монолит, практику.

«Два отдела по-разному называют “клиента”»

Это сигнал разных bounded context, а не задачи «свести всё в одну таблицу Customer». У отдела продаж «клиент» — контакт и сделка; у биллинга — плательщик и договор. Общая таблица без перевода смыслов приводит к полям «client_type_2» и вечным багам.

Что делать: контекстная карта (кто upstream/downstream), явный антикоррупционный слой на интеграции. См. доменную модель, Event Storming.

«Легаси трогать нельзя, но нужен новый UI»

Классический Strangler Fig (удушение снаружи): новый фасад принимает трафик, постепенно перенаправляет операции в новый код, старый монолит сужается. Пользователь видит новый интерфейс; ядро меняется по частям. См. Strangler Fig.

---

Как расти в архитектора осознанно

1. Вести минимум один ADR в месяц на своём проекте — даже для маленьких решений (выбор кэша, формат логов).
2. Разобрать один продакшен-инцидент с точки зрения границ и NFR: где была слабая связность, где не хватало лимитов или идемпотентности.
3. Провести архитектурную сессию с командой (Architecture Kata или разбор реального ТЗ).
4. Пройти цепочку в разделе: Основы → NFR → Event Storming → оценка альтернатив → API → микросервисы → итоги.

Карьерные ожидания и мифы про IT — в разделе Карьера в IT.

---

Краткий чек-лист «я на правильном пути»

• Могу объяснить систему за 10 минут на одной схеме контекста и контейнеров.
• Знаю топ-3 NFR продукта и как они отражены в коде/инфре.
• Есть хотя бы 3 ADR по спорным решениям.
• Разработчики участвуют в проектировании, а не только получают готовую диаграмму.
• После релиза смотрю метрики/инциденты и готов скорректировать границы.

Дальше — Практика архитектурного проектирования и оглавление раздела.

---