Программная архитектура: почему решили именно так

Алексей пришёл в компанию ведущим программистом и первые шесть лет провёл на интеграционной шине: продукты IBM, enterprise integration по полной программе, трансформация и перекладывание данных между источниками — сначала продукты для физических лиц, потом заявочные процессы для юридических. Примерно через год он посмотрел, чем занимаются другие архитекторы в его подразделении, решил, что может так же, а может, и лучше, и перешёл в роль, в которой работает уже девять-десять лет. Уйти из интеграционного слоя заставило ощущение, что выхлопа не видно: аутпут посчитать легко — сколько данных пролетело по трубам туда и обратно, — а outcome для конечного клиента слишком далеко. Он пошёл по командам смотреть, где нужен архитектор, и зацепился за человека из бизнеса, который прямо описал боль: не можем, умираем. Это был Александр Павлюк, и следующие пять лет Алексей отдал продуктовой архитектуре в этой бизнес-линии.

Сначала была одна команда, а через полгода сказали «хорошо делаешь» и добавили ещё семь: семь команд — это как минимум семь продуктов, а то и двенадцать, и подходы пришлось менять кардинально. Алексей разместился на уровне межсистемного ландшафта — какими протоколами и откуда лучше забирать данные, где они лежат, — а низкоуровневую архитектуру оставил зрелым сеньорам. Пришлось завести документацию, которой не было вовсе: выбрали C4 за простоту и за то, что она не перегружена, в отличие от тяжёлых корпоративных языков моделирования, которыми в таких масштабах закрывать нечего. Появился репозиторий схем, часть работы автоматизировали, поднялся портал, где всю архитектуру видно, и процесс согласований. Тулинга под это никто не выдал: раз такой умный — напиши сам, покажи результат, а там посмотрим. Насаждали мягко и с поддержкой менеджмента, начиная с более сговорчивых команд, и много ревью Алексей делал за них сам.

ADR команды попросили сами: архитектуру нарисовал — молодец, но почему именно такую, непонятно. Стандартов, по словам Алексея, нет, зато шаблонов много; посмотрели, как делают в разных компаниях, и собрали свой, кастомный, решающий сугубо их проблемы. Сначала выписываются функциональные требования и ранжируются по сложности и влиянию на бизнес: архитектор оценивает примерную сложность, бизнес — нужность фичи, и от чего-то можно отказаться, что-то сделать потом, а что-то никогда. Дальше добавляются ограничения — например, регуляторные, когда ЦБ требует от банка срочно сделать новую штуку, — и риски безопасности, из-за которых часть решений не подходит. Под каждое требование предлагаются альтернативы, они сравниваются по плюсам и минусам, и решение звучит так: выбираю эту, потому что её плюсы закрывают такие-то требования, а с такими-то минусами я готов мириться. Проектирование выходит итеративным: на очередном требовании цепочка решений рассыпается, и всё начинается заново.

RFC и ADR прижились по всей компании, шаблоны у всех свои, а суть одна. Ценность лога проявляется через год, когда приходит новое требование и никуда не помещается: без записи кажется, что кто-то когда-то ошибся, а с ней видно, какой был контекст и какие условия на старте. Александр вспоминает, как на бизнес-стендапе показывал метафору стройки небоскрёба и объяснял, чем она плоха для софта: редко бывает, чтобы посреди стройки пришёл инвестор и попросил вторую половину развернуть на девяносто градусов, — а в разработке так бывает регулярно. Алексей добавляет, что польза видна и здесь и сейчас: разработчик думает, пока пишет, и приносит готовый документ, вокруг которого строится дискуссия, — встреч нужно меньше. Александр добавляет, что шаблон ещё и прокачивает инженеров: старший коллега даёт обратную связь как коуч, подсвечивая вопросики, а не ошибки. Тяжелее всего далось само документирование решений: команды жили в парадигме самодокументируемого кода, но межсистемные связи поверх сервисов банковского ядра через код не поймать. После третьего ADR продавать уже ничего не пришлось.

Сегодня процесс так или иначе работает на всей бизнес-линии: в подразделении Алексея на двух человек приходится около двадцати двух команд, примерно по одиннадцать на каждого, плюс ещё по пять команд там, где выделенных архитекторов нет и они помогают ревью. Продукты в штуках он считать не берётся: бизнес большой, поэтому пришли к концепции услуг — так проще оценить, что конкретно получает пользователь. Догфудинг в этом сегменте почти не работает: инженеры редко бывают владельцами компаний или ИП, без нужного юридического статуса не получить доступ, да и ежедневно этими продуктами они не пользуются. Знание о продукте приходится добывать практиками: сначала discovery, потом event storming — эксперты домена и разработка у доски клеят стикеры с событиями, раскладывают их по таймлайну и прокручивают поток в обратном порядке, чтобы найти пропущенное.

Практику придумал Альберто Брандолини; книгу он выложил на Leanpub и, по словам Алексея, так и не дописал, зато сообщество её адаптировало и добавило свои наборы стикеров. Один из самых ярких разборов — домен HR: пришли люди из привлечения, развития сотрудников, поддержки и аналитики, все говорили «кандидат», а имели в виду разное, и уточняющие вопросы показали, что не всё кандидат, что кандидат, — зато контексты и субдомены нарисовались сами. Участники отмечают: разработчик, увидев процесс целиком, предлагает убрать лишние шаги, а бизнес идёт к юристам выяснять, можно ли так. Подводные камни Алексей очерчивает сам: на простой области это пушка по воробьям, а на технической платформе трудно отделить техническое событие от доменного. Продавали практику как мини-стартап: сделали, показали результат менеджменту, провели внутренние курсы и оформили шаблон проведения — сначала в Miro, потом во внутреннем инструменте. Учиться Алексей советует под конкретную задачу: сам он так впервые взялся за Python, когда понадобились метрики ревью архитектурных решений.