3.1 Основы архитектуры

Обзор и мотивация

Программная архитектура это набор значимых проектных решений, которые дорого менять: структура основных компонентов, отношения между ними и свойства, которыми должна обладать вся система. Воспринимайте её как общую ментальную модель, позволяющую многим людям строить один связный продукт. В небольшой команде архитектура может жить в нескольких головах и развиваться по ходу дела. В большой организации (сотни инженеров, десятки команд, несколько продуктов, годы дорожной карты) архитектура становится тем, что удерживает всех согласованными. Когда она ясна, команды двигаются независимо, не сталкиваясь. Когда она расплывчата, каждая межкомандная зависимость превращается в переговоры, а каждый инцидент в археологический проект.

Для корпораций и государства основы важны ещё больше, потому что системы долгоживущи, жёстко регулируются и разделяются между ведомствами. Налоговая система, платформа пособий, национальная медицинская запись или основная книга банка переживут карьеры людей, построивших её. Решения, которые вы принимаете сегодня о сцеплении, владении данными и атрибутах качества, ограничивают возможное на десятилетие и дольше. Регуляторы и аудиторы всё чаще ожидают документированной, обоснованной архитектуры: свидетельств, что надёжность, безопасность, приватность и доступность были заложены в проект, а не прикручены потом. Правильные основы не академическая забота. Это разница между платформой, адаптирующейся к новым мандатам, и той, которую придётся перестраивать с нуля.

Эта глава охватывает долговечные основы, переживающие технологическую моду: атрибуты качества («-ости»), архитектурно значимые требования, функции пригодности и эволюционную архитектуру, лёгкую документацию с C4 и arc42 и структурированный анализ компромиссов. Это инструменты, позволяющие большой команде рассуждать об архитектуре намеренно, а не случайно.

Ключевые принципы

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

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Тяжёлая архитектура заранее	Ясность координации; меньше поздних сюрпризов в программах с фиксированным объёмом	Решения принимаются, когда знаний меньше всего; медленно; хрупко к изменениям
Возникающая / эволюционная архитектура	Адаптируется к обучению; меньше потерь; поддерживает быструю поставку	Риск дрейфа без функций пригодности; нужна сильная инженерная дисциплина
Формальная оценка в духе ATAM	Строго, проверяемо, выявляет скрытые конфликты	Затратно по времени и экспертизе; избыточно для мелких изменений
Лёгкие ADR + C4	Дёшево, понятно, постепенно, масштабируется на многие команды	Хороши настолько, насколько дисциплина поддерживать их актуальными

Основное напряжение между определённостью и адаптивностью. Государственные программы с фиксированной ценой и критичные для безопасности системы склоняются к большей строгости заранее и формальной оценке, потому что цена позднего изменения или отказа огромна. Быстро движущиеся продуктовые организации склоняются к эволюционным подходам под защитой автоматизации. Большинству больших организаций нужны оба: более тяжёлое управление необратимыми, высоковлиятельными решениями и сквозными заботами и более лёгкое, возникающее проектирование везде остальное. Обе крайности проваливаются по-своему: переархитектурирование тратит годы и ничего не поставляет, а недоархитектурирование порождает клубок, который нельзя ни масштабировать, ни проверить.

Вопросы для обсуждения с командой

Когда два ваших атрибута качества сталкиваются под нагрузкой, какой побеждает и записали ли вы этот порядок приоритетов? Каждая архитектура вынуждает к размену: максимальная согласованность подрывает доступность, жёсткая безопасность добавляет задержку, агрессивное кэширование борется с проверяемостью. В большой команде опасность в том, что разные отряды молча предполагают разные приоритеты, так что один оптимизирует пропускную способность, а другой охраняет строгую согласованность, и конфликт проявляется только во время инцидента. В корпоративной и государственной среде регулятор спросит, какой атрибут вы защитили и почему, поэтому ранжирование должно быть явным и обоснованным, а не фольклором. Принесите ваши сценарии атрибутов качества и ранжируйте их вслух друг против друга, пара за парой, пока порядок не станет однозначным. Затем закодируйте победителя как функцию пригодности, чтобы приоритет держался под давлением срока, а не размывался.
Какие из ваших недавних решений были дверями в одну сторону и получили ли они больше внимания, чем двери в обе стороны? Проектирование по риску велит тратить усилия на проектирование пропорционально трудности обращения решения, однако большинство команд рассматривают каждое изменение примерно с одной и той же церемонией. Это растрачивает внимание на дешёвые обратимые выборы, пока необратимые (модель данных, вшитая в юридическую запись, контракт публичного API, основное хранилище данных) проскальзывают с недостаточным оспариванием. Возьмите значимые решения прошлого квартала и рассортируйте по обратимости, затем спросите, получили ли необратимые прототипы, исследовательские заделы или формальное рассмотрение. В долгоживущих корпоративных и государственных системах цена неверной двери в одну сторону нарастает десятилетие, поэтому дополнительная строгость окупается многократно. Соразмеряйте вес процесса с обратимостью решения, а не с размером diff.
Для вашего следующего высокорискового трудно обратимого решения, кто должен быть в комнате и по каким сценариям вы будете оценивать варианты? Структурированное рассмотрение компромиссов в духе ATAM оправдывает свою стоимость, когда решение необратимо и затрагивает сразу несколько атрибутов качества, а его сила идёт от присутствующих людей: поставка, безопасность, эксплуатация и владельцы политики или бизнеса, ощущающие последствия. Пропустите один из этих голосов, и вы обнаружите конфликт после построения, как выбор кэширования может тихо сломать требование проверяемости. Принесите приоритизированные сценарии атрибутов качества как критерий оценки и ищите точки чувствительности, где один вариант резко качает один атрибут, и точки компромисса, где он двигает несколько. Нужный вам результат это короткий ADR, фиксирующий отвергнутые варианты и причины, чтобы рассуждение пережило принявших его людей. Если ни одно предстоящее решение, кажется, не оправдывает этого, это само по себе стоит проверить, потому что большая программа без необратимых решений на горизонте обычно просто недостаточно далеко смотрит.
Если бы у нового сотрудника или внешнего аудитора была только ваша письменная архитектура, мог бы он восстановить, почему система устроена так, и когда вы в последний раз это проверяли? Архитектура, живущая в нескольких головах старших, единая точка отказа: когда эти люди уходят, обоснование каждого трудно обратимого решения уходит с ними, а следующая команда заново учит его через инциденты. Для большой организации понятность архитектуры (диаграммы C4, соответствующие реальности, повествование arc42, ADR, фиксирующие отвергнутые варианты) позволяет десяткам команд рассуждать об одной системе без совещания. Принесите недавний ADR и актуальную диаграмму, отдайте их тому, кто не строил компонент, и посмотрите, как далеко он продвинется, прежде чем ему придётся спросить человека. В корпоративной и государственной среде аудитор проделает именно это упражнение, а документация, описывающая систему прошлого года, хуже её отсутствия, потому что вводит в заблуждение тех самых людей, которые должны её сертифицировать. Воспринимайте свежесть письменной записи как измеримое свойство и поставьте за поддержанием её истинности функцию пригодности или периодичность пересмотра.
Какие из ваших архитектурных характеристик сегодня защищены автоматической функцией пригодности, а какие по-прежнему держатся на том, что все помнят правило? Замысел, живущий только на странице вики или в памяти рецензента, размывается в момент наступления срока, потому что правило слоёв, граница «без общей базы данных» и бюджет задержки именно то, что команды режут под давлением. В большой быстро меняющейся кодовой базе выживает только тот замысел, который обеспечивает сборка, поэтому разрыв между заявленными характеристиками и теми, что вы действительно проверяете, ваш реальный архитектурный риск. Перечислите ваши значимые характеристики, отметьте каждую как обеспечиваемую, проверяемую вручную или незащищённую и принесите три последних случая, когда ревью поймало дрейф, который функция пригодности могла бы поймать раньше. В регулируемых и государственных системах это важно вдвойне, потому что регулятор спросит не о том, намеревались ли вы обеспечить размещение данных или проверяемость, а о том, как вы докажете, что они непрерывно выполнялись, и зелёный конвейер гораздо более сильный ответ, чем документ политики. Приоритизируйте автоматизацию характеристик, чей отказ одновременно вероятен и дорог, и примите, что некоторые останутся ручными.
Когда вы решаете, архитектурно ли значимо требование, кто принимает это решение и как не дать списку ASR стать «всем» или «ничем»? Ценность называния архитектурно значимых требований идёт от избирательности: воспринимайте каждое требование как значимое, и проектирование остановится, не воспринимайте ни одно, и структурные, рискованные, трудно изменяемые проскользнут незащищёнными. В большой команде есть соблазн дать каждому отряду решать локально, что порождает непоследовательные планки и межкомандные сюрпризы, когда «мелкий» выбор одной группы ограничивает структуру другой. Принесите ваш текущий список ASR, критерии, которыми вы пользовались (затрагивает многие компоненты, дорого удовлетворяется, жёсткое ограничение, технически рискованно), и несколько пограничных требований, чтобы проверить границу вслух. Для корпораций и государства регуляторные мандаты вроде размещения данных, хранения и проверяемости почти всегда значимы и не подлежат обсуждению, поэтому назовите, кто владеет списком, как он пересматривается и как записывается решение добавить или убрать ASR, потому что ASR, которым никто не управляет, это требование, которое никто не защитит под проверкой.

Взгляд по секторам

Стартап. Держите церемонию близкой к нулю, а запись близкой к полной. Пропустите формальные семинары ATAM и тяжёлые шаблоны, но всё же напишите дюжину коротких ADR для выборов, которые было бы больно отменять (хранилище данных, монолит или сервисы, провайдер аутентификации), и закрепите два-три сценария атрибутов качества, которые ваши первые клиенты действительно ощущают. Ваш дефицитный ресурс инженерное внимание, поэтому защищайте только те характеристики, чей отказ вас потопит, например изоляцию арендаторов, а всё остальное оставьте возникающим и дёшево изменяемым.

Малый бизнес. Без выделенного архитектора и при ограниченном бюджете опирайтесь на основы, стоящие почти ничего: назовите вашу горстку атрибутов качества конкретными числами, пишите ADR для всего, что вам было бы трудно обратить, и позвольте выбранной платформе или поставщику нести тяжёлые структурные решения. Предпочитайте покупку хорошо поддерживаемого стека построению заказной инфраструктуры и воспринимайте задокументированную архитектуру поставщика как ограничение, которое вы наследуете, а не то, которое нужно писать с нуля.

Крупная организация. Трудность в связности между многими командами и годами дорожной карты, поэтому вкладывайтесь в общую машинерию: гильдию архитектуры, общий набор сценариев атрибутов качества, ADR рядом с кодом и функции пригодности в CI, обеспечивающие границы, которые не смог бы контролировать ни один рецензент в масштабе. Используйте структурированный анализ компромиссов для необратимых сквозных решений, держите диаграммы C4 общей картой на ревью проектов и управляйте списком ASR централизованно, чтобы группы перестали принимать локально разумные выборы, сталкивающиеся глобально.

Государственный сектор. Долгоживущие регулируемые системы делают документированную обоснованную архитектуру требованием закупок и подотчётности, а не любезностью. Воспринимайте размещение данных, хранение, проверяемость и доступность как архитектурно значимые требования, записанные в описании arc42, которое аудиторы могут читать напрямую, и проводите лёгкие семинары по компромиссам с участием должностных лиц по политике и безопасности, чтобы конфликты (например, кэширование против проверяемости) всплывали на бумаге до кода. Держите след рассуждений достаточно полным, чтобы ответственное должностное лицо могло показать должную осмотрительность, и предпочитайте архитектуры с ясными вариантами выхода тем, что привязывают государственный орган к единственному поставщику на десятилетие.

Примеры

Стартап. Команда SaaS на начальной стадии из шести человек хранит архитектуру в общем документе, а не в формальном процессе, но всё же записывает решения, которые было бы больно обращать. Они фиксируют около дюжины ADR (почему Postgres вместо документного хранилища, почему модульный монолит вместо сервисов, почему выбран именно такой провайдер аутентификации) и закрепляют два сценария атрибутов качества, действительно важных ранним клиентам: «регистрация завершается менее чем за две секунды» и «ни один клиент никогда не может прочитать данные другого арендатора». Когда они нанимают седьмого и восьмого инженеров, эти заметки позволяют новичкам выпускать результат в первую неделю, а не прерывать всех вопросом, почему всё устроено так.

Крупная организация. Международный банк консолидирует двенадцать региональных платёжных систем и создаёт небольшую гильдию архитектуры. Гильдия определяет восемь сценариев атрибутов качества (включая «обрабатывать 10 000 транзакций в секунду без единой потерянной транзакции» и «восстанавливать регион за 15 минут»), фиксирует примерно сорок ADR и обеспечивает функции пригодности в CI (непрерывной интеграции): ни один сервис не может писать в базу данных другого домена, все вызовы между сервисами должны трассироваться, а любая зависимость с критическим CVE (Common Vulnerabilities and Exposures) валит сборку. Диаграммы контекста и контейнеров C4 становятся общей картой на каждом ревью проекта, а межкомандные споры об интеграции резко сокращаются.

Государственный сектор. Национальное агентство модернизирует платформу пособий, и закон требует от него гарантировать размещение данных, семилетнюю проверяемость и соответствие доступности. Его архитекторы воспринимают их как ASR и записывают в описание arc42, которое аудиторы рассматривают напрямую. Они проводят лёгкий семинар ATAM с командами поставки, безопасностью и должностными лицами по политике, чтобы сравнить две кандидатские архитектуры, и обнаруживают, что стратегия кэширования предпочтительного проекта конфликтует с требованием проверяемости. Поимка этого компромисса на бумаге, до единой строки кода, экономит месяцы переделок и даёт ответственному министру документированное свидетельство должной осмотрительности.

Бизнес-обоснование: мотивы, ROI и TCO

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

Для руководства формулируйте обоснование вокруг вариативности и риска. Хорошие основы архитектуры снижают стоимость будущих изменений (прямой рычаг скорости поставки и совокупной стоимости владения на десятилетнем сроке жизни системы), уменьшают частоту и длительность серьёзных инцидентов и создают след документации, которого теперь требуют регуляторы и аудиторы. Одна лишь привычка ADR окупается в первый раз, когда новая команда руководства спрашивает «почему мы построили это так?» и получает ответ за минуты вместо судебного расследования. Назовите числа, где можете: сопоставьте стоимость одного избегнутого крупного перепроектирования или одного избегнутого проваленного аудита с небольшой текущей стоимостью практик.

Антипаттерны и ловушки

Архитектура в башне из слоновой кости. Архитекторы, производящие диаграммы, но никогда не касающиеся кода и не говорящие с командами поставки; их проекты игнорируются или нереализуемы.
Атрибуты качества как прилагательные. «Масштабируемый, безопасный, надёжный» без чисел, без сценариев и потому без способа проверить или разменять.
Большой предварительный проект. Фиксация каждой детали до первой строки кода, закрепление решений, когда понимание слабее всего.
Документация, которая лжёт. Диаграммы, описывающие систему прошлого года; хуже отсутствия, потому что вводят в заблуждение.
Проектирование ради резюме. Выбор технологий, чтобы строить карьеры, а не удовлетворять ASR.
Позолота. Проектирование под масштаб, гибкость или общность, которых требования не просили, навсегда добавляющее стоимость и сложность.
Нет архитектурных ограждений. Опора на добрые намерения вместо функций пригодности для сохранения структуры в большой команде.

Модель зрелости

Уровень 1: Начальный. Архитектура неявна и живёт в головах отдельных людей. Нет документированных атрибутов качества, ADR или общих диаграмм. Структура обнаруживается во время инцидентов, и каждая межкомандная зависимость заново согласуется с нуля.
Уровень 2: Развитие. Некоторые команды записывают решения, которые было бы больно обращать, и набрасывают ключевые диаграммы, но практика непоследовательна: один отряд ведёт ADR, другой нет, атрибуты качества называются прилагательными, а не измеримыми сценариями, и документация дрейфует от устаревшей между проектами.
Уровень 3: Стандартизация. Сценарии атрибутов качества и архитектурно значимые требования описаны и приоритизированы по документированному стандарту всей организации. ADR рутинны и хранятся рядом с кодом, документация C4 и arc42 поддерживается по общему шаблону, а структурированные рассмотрения компромиссов обязательны для значимых решений в каждой команде.
Уровень 4: Управление. Архитектура измеряется относительно базовых значений, а не декларируется. Функции пригодности в CI сообщают о характеристиках вроде задержки p99, нарушений слоёв, нетрассируемых вызовов и уязвимых зависимостей; охват ADR и свежесть документации отслеживаются как метрики; рассмотрения компромиссов оценивают варианты по приоритизированным сценариям; а дрейф относительно согласованных базовых значений запускает определённый ответ вместо сюрприза. Аудиторы могут опираться на измеренные свидетельства, а не только на повествование.
Уровень 5: Оркестрация. Архитектура эволюционирует непрерывно и адаптивно по всей организации. Данные функций пригодности и инцидентов возвращаются в то, какие характеристики важны и куда направляются усилия проектирования; списки ASR, приоритеты атрибутов качества и ограждения пересматриваются по мере смещения мандатов и рисков; а практика интегрирована с поставкой, безопасностью и планированием рисков, так что платформа адаптируется к новым требованиям, а не перестраивается с нуля.

Идеи для обсуждения

Какие три атрибута качества действительно не подлежат обсуждению для вашей самой критичной системы и можете ли вы сегодня описать каждый измеримым сценарием?
Как вы решаете, достаточно ли решение «архитектурно значимо», чтобы заслужить ADR, а не просто выполнить его?
Где функции пригодности поймали бы дрейф, который пропускает ваше нынешнее ревью кода?
Занимается ли ваша организация переархитектурированием или недоархитектурированием и какие свидетельства подсказывают, что именно?
Кто отвечает за архитектуру в структуре «команда команд» и как избежать и башни из слоновой кости, и полной анархии?
Как внешний аудитор восстановил бы замысел вашей архитектуры по тому, что записано сегодня?

Главные выводы

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

Источники и дополнительное чтение

Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice
Neal Ford, Rebecca Parsons, and Patrick Kua, Building Evolutionary Architectures
Simon Brown, Software Architecture for Developers (and the C4 model)
Mark Richards and Neal Ford, Fundamentals of Software Architecture
George Fairbanks, Just Enough Software Architecture: A Risk-Driven Approach
Michael Nygard, “Documenting Architecture Decisions” (the ADR pattern)
Gernot Starke and Peter Hruschka, arc42 documentation template
Paul Clements et al., Evaluating Software Architectures: Methods and Case Studies (ATAM)
ISO/IEC 25010, Systems and software quality models

3.1 Основы архитектуры

Обзор и мотивация

Ключевые принципы

Рекомендации

Описывайте атрибуты качества как измеримые сценарии

Выявляйте архитектурно значимые требования (ASR)

Принимайте эволюционную архитектуру и функции пригодности

Документируйте с помощью C4 и arc42

Проводите структурированный анализ компромиссов и ведите проектирование по риску