«Архитектор» в живой продуктовой команде — это не должность «рисует квадратики и уходит». Это набор обязанностей, которые кто-то обязан нести — выделенный человек, тимлид или сильный разработчик по совместительству. Эта статья — список этих обязанностей и честный разбор, какие из них сегодня автоматизируются ucp-скиллами, а какие остаются человеческим суждением.
Сквозная идея: AI не принимает архитектурных решений — он держит карту актуальной, готовит материал для решения и проверяет согласованность после. Решает и отвечает за последствия — архитектор.
1. Держать карту системы
Реестр сервисов, context map, владение данными, ubiquitous language: кто чем владеет, кто с кем интегрирован, какие термины что значат. Без карты любой следующий вопрос («куда положить новую функциональность?») решается по памяти и по-разному.
Скиллы. ucp-arch-design заводит новый сервис на платформенном уровне: карточка сервиса, запись в реестр, обновление context map и владения данными — с проверкой конфликтов ownership и языка. ucp-arch-query отвечает на вопросы по корпусу («кто владеет сущностью X?», «кто потребляет событие Y?») без ручного перекапывания. ucp-arch-sync зеркалирует спеки сервисов в архитектурный репозиторий — карта не дрейфует от реальности, источник правды остаётся в репо сервиса.
2. Решать развилки — и записывать решения
Монолит или микросервисы, PG или ClickHouse, sync или async — развилки этого раздела. Обязанность архитектора — не «знать правильный ответ», а провести решение по критериям, честно взвесить, зафиксировать ADR и защитить его от пересмотра-по-забывчивости.
Скиллы. Здесь автоматизации меньше всего — и это правильно: trade-off между «лишний stateful-компонент» и «аналитика душит прод» зависит от команды, бюджета и горизонта, которых нет в коде. AI помогает подготовкой: собрать факты по чек-листам (объёмы, нагрузка, потребители — ucp-arch-query по корпусу), набросать черновик ADR с альтернативами. Решение и подпись — человеческие.
3. Проектировать границы контекстов
Где заканчивается «Заказ» и начинается «Доставка», какие инварианты внутри, какие события наружу. Ошибка границы — самая дорогая ошибка проектирования: она расползается в контракты, команды и оргструктуру.
Скиллы. ucp-spec-design превращает бизнес-описание в Use Case спецификацию bounded context-а — команды, события, инварианты, акторы. ucp-spec-review работает design-критиком: ловит перегруженные агрегаты, отсутствующих акторов, непокрытые зоны отказа, размытый язык. ucp-spec-tier-0 снимает as-is спеку с существующего кода — отправная точка, когда границы надо не придумать, а сначала увидеть. Архитектору остаётся главное: решить, где резать — скиллы делают рез аккуратным и проверенным.
4. Проектировать сквозные бизнес-процессы
Оформление заказа проходит через четыре сервиса — кто оркестрирует, где компенсации, что происходит при отказе третьего шага. Это уровень выше одного сервиса, и он чаще всего вообще нигде не записан.
Скиллы. ucp-arch-bp-design оформляет процесс как артефакт: BP-карточка с sequence-диаграммой, выбором orchestration/choreography, точками отказа и компенсациями, с обновлением карточек сервисов-участников. Решение «оркестратор или хореография» — снова человеческое (см. sync vs async); скилл гарантирует, что решение записано полно и единообразно.
5. Оценивать impact изменений
«Поменяем поле в событии OrderPaid» — кого сломает? Ответ «вроде никого» — то, с чего начинаются худшие инциденты. Обязанность архитектора — чтобы такие вопросы имели проверяемый ответ.
Скиллы. ucp-arch-impact строит граф зависимости по корпусу: какие сервисы потребляют контракт/событие/UC, какие BP-процессы проходят через него, что попадает под изменение. Это та работа, которую человек делает грепом и опросом в чате — медленно и с пропусками; машина делает её за минуты и без «забыл про сервис нотификаций».
6. Охранять согласованность платформы
Спеки дрейфуют от кода, термины расползаются («клиент», «покупатель» и «юзер» — одно и то же?), два сервиса объявляют себя владельцами одной сущности. По одному случаю это мелочи; накопившись, они делают карту бесполезной.
Скиллы. ucp-arch-consistency-review — периодическое ревью корпуса по правилам R-ARCH-*: реестр против карточек, context map против контрактов, язык против глоссария, ownership без конфликтов. Запускается после крупных изменений или раз в спринт — дрейф ловится, пока дёшев. Это типичная «вторая половина» работы архитектора, на которую у живого человека никогда нет времени, — и ровно поэтому её стоит отдать машине.
7. Превращать стандарты в исполняемые
Решение архитектора, не превращённое в проверяемое правило, умирает за два спринта. «Договорились не звать сервисы синхронно из листенеров» работает, только если это ловится на ревью каждый раз.
Скиллы. Это весь слой style-guide + review-скиллов: каждое правило имеет код (R-API-*, R-KFK-*, R-DIST-*...), каждый гайд — парный review-скилл, который применяет правила к diff-у. Архитектурное решение оформляется не меморандумом, а правилом в гайде — и дальше проверяется на каждом PR без участия автора. Подробно этот подход разобран в executable engineering standard.
Сводная таблица
| Обязанность | Что делает скилл | Что остаётся человеку |
|---|---|---|
| Карта системы | ucp-arch-design, ucp-arch-query, ucp-arch-sync — реестр, context map, актуальность | Решение, нужен ли новый сервис вообще |
| Развилки и ADR | Сбор фактов, черновик ADR | Само решение и ответственность |
| Границы контекстов | ucp-spec-design, ucp-spec-review, ucp-spec-tier-0 | Где провести границу |
| Бизнес-процессы | ucp-arch-bp-design — BP-карточка, диаграмма, компенсации | Orchestration vs choreography |
| Impact изменений | ucp-arch-impact — полный граф затронутого | Решение «меняем / версионируем / не трогаем» |
| Согласованность | ucp-arch-consistency-review — дрейф, язык, ownership | Разруливание конфликтов владения |
| Стандарты | Review-скиллы с кодами правил на каждом PR | Какие правила вообще нужны команде |
Закономерность в правой колонке: человеку остаются решения с trade-off и ответственностью, машине уходит полнота — карта без пропусков, ревью без усталости, impact без «забыл». Архитектор без скиллов тонет в рутине поддержания карты; скиллы без архитектора аккуратно документируют хаос.
Что почитать дальше
- ADR — журнал решений, главный личный артефакт этой роли.
- Настройка Claude Code под UCP — каталог и установка упомянутых скиллов.
- Executable engineering standard — стандарты, которые проверяются, а не вспоминаются.
- Модель C4 — язык диаграмм для карты из пункта 1.