Российский архитектор из Кинопоиска Дмитрий Бардин выпустил 400-страничное «Практическое руководство для архитекторов решений» — книгу о том, как архитектор решений связывает разработку отдельного продукта с ландшафтом всей компании. Для техлидов, аналитиков и инженеров, которым пора отвечать не только за код, но и за последствия технических компромиссов, это попытка разложить профессию без мистики и героических легенд.
Книга вышла в 2026 году в серии «Профессиональное программирование», включает девять глав. Как сообщает Habr / Карьера, Бардин написал ее после опыта руководства группой архитекторов: ему пришлось искать способ выращивать специалистов из сильных разработчиков и инженеров. В результате получился не учебник по конкретному стеку, а набор практик, нотаций и вопросов, с которыми сталкивается человек на стыке бизнеса, продуктов, данных и инфраструктуры.
Издание не рассчитано на стажеров и джунов. Паттерны SAGA, CQRS и Data Vault 2.0 здесь не разжевываются с нуля: автор предполагает, что читатель уже видел подобные задачи в продакшене, на код-ревью или хотя бы в обсуждениях проектирования. Основная аудитория — ведущие разработчики и техлиды, системные и бизнес-аналитики, DevOps-инженеры, руководители проектов, пресейл-команды и CTO небольших компаний, которым нужно выстраивать архитектурную практику почти с чистого листа.
Не «главный разработчик», а человек, который держит границы
В первых главах Бардин разводит архитектуру и дизайн, сопоставляет определения из ГОСТ Р 57100–2025, работ Гради Буча и Мартина Фаулера. Полезнее всего здесь не терминологический спор, а описание типичных сбоев в роли. Например, когда архитектор одновременно ведет проект, нанимает людей, закрывает зависшие задачи и иногда пишет код между созвонами. Формально архитектурный совет в компании может существовать, но решения принимаются размыто, а ответственность остается в том числе за людьми, давно покинувшими команду.
Дальше книга сравнивает бизнес-, корпоративную, техническую и solution-архитектуру, рассматривает четыре домена — бизнес, данные, приложения и инфраструктуру — и показывает, как роль меняется в водопадных проектах, Agile и SAFe. В гибкой разработке архитектура перестает быть чертежом, который однажды утвердили и положили в Confluence: она проходит через последовательность переходных состояний от текущего ландшафта к целевому.
Отдельный блок посвящен тому, как архитектор решений формулирует требования. Функциональная часть остается зоной плотной работы аналитика, а архитектор фокусируется на нефункциональных ограничениях: надежности, производительности, масштабировании, безопасности и стоимости изменений. В ход идут модели качества ISO 25010 и МакКолла, приоритизация MoSCoW, архитектурно значимые требования и сценарии атрибутов качества. Для продуктовых команд это важное напоминание: фраза «сделаем быстро и надежно» не является требованием, пока не появились измеримые условия и понятные компромиссы.
От Event Storming до Data Mesh и RAG
Книга уделяет внимание и инструментам разговора между бизнесом и инженерами. В главе о функциональной архитектуре собраны UML, IDEF, EPC, DFD, BPMN и Archimate — с акцентом на выбор нотации под задачу и аудиторию, а не на коллекционирование диаграмм. Event Storming показан как практический способ собрать на одной доске разработчиков, аналитиков и представителей бизнеса, восстановить ход процесса и увидеть спорные места до того, как они превратятся в дорогую интеграцию.
Около 70 страниц отведено архитектуре данных. Автор различает Data Governance и Data Management, разбирает качество данных и эволюцию платформ: DWH по Кимбаллу и Инмону, Data Vault 2.0, Data Lake, Lakehouse, Data Fabric и Data Mesh. Важная деталь — Data Mesh рассматривается не как повод выбросить работающие хранилища, а как вариант сосуществования с уже накопленными DWH и озером данных. Здесь же есть DataOps, ETL и ELT, Zero ETL, DAMA-DMBOK, модели зрелости, TCO, ROI и различие между приватностью данных и их безопасностью.
Самая большая глава, более 100 страниц, посвящена архитектуре приложений и техническим решениям: API и протоколам, интеграционным платформам, SOA, микросервисам, событийному подходу и serverless. Бардин проходит через выбор баз данных с учетом CAP и PACELC, моделей ACID и BASE, а также упоминает векторные БД для RAG-сценариев. Это не каталог технологий и не обещание, что микросервисы автоматически исправят организационные проблемы. Скорее, карта мест, где техническое решение неизбежно упирается в стоимость владения, данные, границы команд и скорость поставки.
Книга почти не использует код: встречаются короткие контракты и архитектурные тесты, но разработчику не предложат готовый шаблон сервиса на любимом языке. Это ограничение одновременно делает материал доступнее аналитикам и менеджерам. Для инженера ценность будет в другом — в языке, который помогает объяснить, почему выбор очередного брокера, базы или схемы интеграции нельзя сводить к личным предпочтениям команды.
На российском рынке, где архитектор решений нередко оказывается и техлидом, и кризис-менеджером, и последней инстанцией по любому «а давайте быстро», такой разбор роли выглядит своевременным. Главный вопрос после чтения не в том, какой паттерн выбрать, а готова ли компания дать архитектуре реальные полномочия и ответственность — или продолжит называть архитектором самого опытного человека, которому просто добавили встреч в календарь.