Переводчик С. Черников

 

Марк Ричардс , Нил Форд

Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы. — СПб.: Питер, 2023.

 

ISBN 978-5-4461-1842-7

© ООО Издательство "Питер", 2023

 

Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.

 

Отзывы о книге «Фундаментальный подход к программной архитектуре»

Нил и Марк — не только выдающиеся архитекторы ПО, но и замечательные наставники. В книге «Фундаментальный подход к программной архитектуре» благодаря своему многолетнему опыту им удалось в сжатом виде изложить обширнейшую тему архитектуры ПО. Кем бы вы ни были, новичком или архитектором с многолетней практикой, эта книга поможет поднять ваш профессиональный уровень. Очень жаль, что она не появилась на заре моей карьеры.

Натаниэль Шутта (Nathaniel Schutta), архитектор и девелопер-адвокат VMware, ntschutta.io

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

Ребекка Дж. Парсонс (Rebecca J. Parsons), CTO, ThoughtWorks

Марк и Нил дают реальные практические советы, позволяющие специалистам достичь архитектурного совершенства. Они рассказывают о наиболее распространенных архитектурных свойствах и компромиссах, знание которых необходимо для успешной работы.

Кэсси Шум (Cassie Shum), технический директор, ThoughtWorks

Предисловие. Развенчание аксиом

Аксиома

Утверждение или суждение, которое считается установленным, принятым или бесспорно истинным.

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

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

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

Те, кто на протяжении длительного времени внимательно следил за развитием архитектуры ПО, стали свидетелями эволюции возможностей. Все инновации, начиная с экстремального программирования2, с последующим переходом к непрерывной доставке, DevOps-революции, микросервисам, контейнеризации и современным облачным ресурсам, приводили к новым возможностям и компромиссам. По мере изменения возможностей менялись и взгляды архитекторов на производство программных продуктов. В течение многих лет не без иронии говорилось, что архитектура — «это то, что изменить впоследствии весьма непросто». Затем появились микросервисы, где изменение является важнейшей особенностью дизайна.

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

Разработчики давно хотели превратить разработку ПО из ремесла, в котором талантливые мастера могут создавать единичные проекты, в инженерную дисциплину, подразумевающую повторяемость, строгость и эффективный анализ. Хотя программная инженерия все еще ощутимо отстает от других инженерных дисциплин (справедливости ради следует отметить, что создание ПО — очень молодая дисциплина по сравнению с другими), архитекторы внесли в нее существенные улучшения, с которыми нам предстоит познакомиться. В частности, современные методы гибкой разработки с применением Agile-технологии позволили добиться больших успехов в разработке новых типов систем, проектируемых архитекторами.

Мы также рассмотрим чрезвычайно важный вопрос анализа компромиссов. Разработчику ПО легко увлечься определенной технологией или подходом. Но архитекторы всегда должны трезво оценивать все хорошее, плохое и уродливое в каждом варианте, ведь в реальном мире практически ничто не предлагает удобных двоичных вариантов выбора — все в нем соткано из компромиссов. С этой прагматической точки зрения мы стремимся исключить оценочные суждения о технологиях и сосредоточиться на анализе компромиссов, чтобы вооружить наших читателей аналитическим взглядом на выбор технологий.

Наша книга не сможет волшебным образом превратить вас в первоклассного специалиста по архитектуре ПО — это достаточно сложная область знаний с множеством нюансов. Мы хотим предложить действующим и активно развивающимся архитекторам полезный и актуальный обзор архитектуры ПО и ее многочисленных аспектов, от структуры до нужных архитектору навыков межличностного общения. Хотя в этой книге рассматриваются хорошо известные паттерны, мы применяем новый подход, опираясь на накопленный нами опыт, используемые инструменты, практику проектирования и другие материалы. Мы берем многие существующие в архитектуре программного обеспечения аксиомы и переосмысливаем их в свете текущего состояния экосистемы; мы проектируем архитектуры с учетом современного ландшафта.

Условные обозначения

В этой книге используются следующие условные обозначения:

Курсив

Курсивом выделены новые термины или важные понятия.

Моноширинный шрифт

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

Моноширинный полужирный шрифт

Показывает команды или другой текст, который пользователь должен ввести самостоятельно.

Моноширинный курсив

Показывает текст, который должен быть заменен значениями, введенными пользователем, или значениями, определяемыми контекстом.

Шрифт без засечек

Используется для обозначения URL, адресов электронной почты, названий кнопок и других элементов интерфейса, каталогов.

Этот рисунок указывает на совет или предложение.

Использование исходного кода примеров

Вспомогательные материалы (примеры кода, упражнения и т.д.) доступны для загрузки по адресу http://fundamentalsofsoftwarearchitecture.com. Если у вас возникнут вопросы технического характера по использованию примеров кода, направляйте их по электронной почте на адрес bookquestions@oreilly.com.

В общем случае все примеры кода из книги вы можете использовать в своих программах и в документации. Вам не нужно обращаться в издательство за разрешением, если вы не собираетесь воспроизводить существенные части программного кода. Если вы разрабатываете программу и используете в ней несколько фрагментов кода из книги, вам не нужно обращаться за разрешением. Но для продажи или распространения примеров из книги вам потребуется разрешение от издательства O’Reilly. Вы можете отвечать на вопросы, цитируя данную книгу или примеры из нее, но для включения существенных объемов программного кода из книги в документацию вашего продукта потребуется разрешение.

Мы рекомендуем, но не требуем добавлять ссылку на первоисточник при цитировании. Под ссылкой на первоисточник мы подразумеваем указание авторов, издательства и ISBN.

За получением разрешения на использование значительных объемов программного кода из книги обращайтесь по адресу permissions@oreilly.com.

У этой книги есть веб-страница с перечнем замеченных опечаток и другой дополнительной информацией, доступ к которой можно получить по адресу https://oreil.ly/fundamentals-of-software-architecture.

Благодарности

Мы, Марк и Нил, благодарим всех, кто посещал наши занятия, семинары, серии конференций, собрания групп пользователей, а также всех людей, прослушавших версии этого материала и предоставивших свои бесценные отзывы. Также мы благодарим команду издательства O’Reilly, оказавшую максимально возможное содействие в написании книги. Спасибо директору No Stuff Just Fluff Джею Циммерману (Jay Zimmerman), организовавшему серию конференций, в результате которых удалось расширить техническое содержимое книги, и всем другим ораторам, чьи отзывы и мокрые от наших слез плечи мы бесконечно ценим. Мы также благодарны ряду случайно оставшихся оазисов здравомыслия, способных вдохновить на смелые замыслы, в виде групп с именами, похожими на Pasty Geeks и Hacker B&B.

Благодарности от Марка Ричардса

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

Благодарности от Нила Форда

Хочу поблагодарить свою большую семью — коллектив ThoughtWorks, и в частности Ребекку Парсонс (Rebecca Parsons) и Мартина Фаулера (Martin Fowler). Компания ThoughtWorks — замечательная команда, способная создавать ценности для клиентов, внимательно отслеживая, как работают те или иные вещи, чтобы мы могли их улучшить. Компания ThoughtWorks поддерживала работу над этой книгой всевозможными способами и продолжает повышать профессио­нальный уровень своих сотрудников, ведущих повседневную борьбу с трудностями и вдохновляющих на победу над ними. Хочу также поблагодарить работников соседнего коктейль-клуба за возможность отдохнуть от рутинной работы. И наконец, хочу сказать спасибо своей жене Кэнди, чье терпеливое отношение к написанию мною книги и участию в различных конференциях воистину не знало границ. Не один десяток лет она поддерживала во мне реальный взгляд на вещи и здравомыслие, настраивая на плодотворный труд, и я надеюсь, что еще не одно десятилетие она будет любовью всей моей жизни.

---

От издательства

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

Для вашего удобства мы собрали в таблицу небольшой словарь паттернов, упоминаемых в книге.

СЛОВАРЬ ПАТТЕРНОВ И АНТИПАТТЕРНОВ ПРОЕКТИРОВАНИЯ

Bullet-Riddled Corpse	Тело, изрешеченное пулями
Covering Your Assets (антипаттерн)	Излишняя перестраховка
Email-Driven Architecture (антипаттерн)	Архитектура, управляемая имейлами
Groundhog Day (антипаттерн)	День сурка
Антипаттерн архитектурной воронки	Architecture sinkhole pattern
Антипаттерн бессистемной архитектуры	Accidental architecture antipattern
Антипаттерн подразумеваемой архитектуры	Architecture by implication antipattern
Башня из слоновой кости (антипаттерн)	Ivory Tower
Большой ком грязи (антипаттерн)	Big Ball of Mud
Душитель	Strangler
Замороженный троглодит (антипаттерн)	Frozen Caveman
Западня сущности (антипаттерн)	Entity trap
Локатор сервисов	Service Locator
Модель — Представление — Контроллер	Model-View-Controller
Паттерн Backends for Frontends (BFF)	Обычно не переводится
Паттерн sidecar	Обычно не переводится
Паттерн делегирования	Business delegate pattern
Паттерн саги	Saga pattern
Паттерн событий рабочего процесса	Workflow event pattern
Паттерн фронт-контроллера	Front controller pattern
Стратегия	Strategy
Шаблонный метод	Template Method

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

Глава 1. Введение

Специальность «архитектор программного обеспечения» находится в верхних строчках многочисленных рейтингов вакансий по всему миру. Но когда читатели смотрят на другие специальности в этих списках (например, фельдшер или экономист), то видят вполне определенный путь профессионального роста. Так почему же развитие карьеры архитектора программного обеспечения мало кому понятно?

Во-первых, в самой профессиональной среде отсутствует четкое определение архитектуры программного обеспечения (ПО). При чтении установочных лекций студенты часто просят дать краткое описание того, чем занимается архитектор ПО, но мы отвечаем уклончиво. И не мы одни. В своей знаменитой статье «Who Needs an Architect?» («Кому нужен архитектор?»)3 Мартин Фаулер (Martin Fowler), как известно, отказался от попытки дать четкое определение соответствующему понятию, вернувшись вместо этого к известной цитате:

Архитектура — это о важном… что бы это ни было.

Ральф Джонсон (Ralph Johnson)

Однажды нам все же пришлось создать ментальную карту (майндмэп), показанную на рис. 1.1, которая, к сожалению, не является исчерпывающей, но при этом показывает масштаб архитектуры ПО. Через некоторое время мы предложим свое определение этому понятию.

Во-вторых, как показано на схеме, зона ответственности архитектора ПО весьма велика и постоянно расширяется. Лет десять назад архитекторы программного обеспечения занимались чисто техническими аспектами архитектуры: модульностью, компонентами и паттернами. Но благодаря появлению новых архитектурных стилей с более широким спектром возможностей (например, микросервисов, обязанности архитектора значительно увеличились. Множество пересечений архитектуры с остальными организационными задачами будет рассмотрено в следующем далее разделе «Пересечение архитектуры и…» (с. 37).

Рис. 1.1. Архитектор ПО должен обладать техническими знаниями, гибкими навыками (soft skills), а также понимать бизнес-процессы и множество других вещей

В-третьих, архитектура ПО — это постоянно меняющаяся концепция, потому что экосистема разработки программного обеспечения слишком быстро развивается. Любое принятое сегодня определение через несколько лет безнадежно устареет. Определение архитектуры ПО в Википедии дает вполне приемлемое общее представление, но многие положения уже неактуальны, например: «Архитектура программного обеспечения относится к выбору фундаментальных структурных решений, внесение изменений в которые после их реализации обходится слишком дорого». Но с тех пор специалисты разработали современные архитектурные стили (микросервисы) с идеей поэтапного встраивания, при котором внесение структурных изменений уже не обходится «слишком дорого». Конечно, эта возможность означает компромисс с другими вопросами, например связанностью. Во многих книгах по программной архитектуре она представляется чисто статической, и считается, что после однократного внедрения ее можно спокойно игнорировать. Однако неизбежная динамическая природа архитектуры ПО, да и самого определения этого понятия прослеживается во всей книге.

В-четвертых, основной объем сведений об архитектуре ПО несет чисто историческую нагрузку. Читателям страницы Википедии, несомненно, бросится в глаза множество сокращений и перекрестных ссылок на целую вселенную знаний. Но многие из этих сокращений, по сути, устарели или не прижились. Даже те методы, которые несколько лет назад представлялись правильными, сейчас не работают, потому что изменился контекст. История развития архитектуры ПО насыщена принятыми решениями, которые в дальнейшем привели к разрушительным последствиям. Многие из этих уроков мы рассмотрим здесь. Так почему же эта книга по основам архитектуры программного обеспечения появилась именно сейчас? В нашем мире все постоянно меняется, и область архитектуры ПО не исключение. Новые технологии, методы, возможности… по сути, в последнем десятилетии проще найти что-то, что не изменилось, чем перечислить все изменения. И архитекторы программного обеспечения вынуждены принимать решения в этой постоянно меняющейся экосистеме. Поскольку изменения касаются практически всего, включая и сами основы принятия наших решений, архитекторы должны каждый раз пересматривать ряд аксиом, на которых базировались предыдущие работы. Например, в ранее вышедших книгах об архитектуре ПО не рассматривалось влияние методологии DevOps, поскольку на момент написания этих книг ее просто не было.

Изучая архитектуру, нужно осознавать, что, как и во многих других искусствах, ее премудрости можно усвоить только в контексте. Многие решения принимаются архитекторами на основе особенностей той среды, в которой они оказались. Например, основной целью архитектуры ПО конца XX века было достижение более эффективного использования общих ресурсов, поскольку вся инфраструктура того времени состояла из дорогих коммерческих продуктов: операционных систем, серверов приложений, серверов баз данных и т.д. Представьте, что вы приходите в дата-центр образца 2002 года и говорите начальнику отдела эксплуатации: «У меня есть отличная идея по внесению кардинальных изменений в сам стиль архитектуры: запуск каждого сервиса будет на отдельной, предназначенной только для него машине, с его собственной выделенной базой данных». (Это суть того, что нам сейчас известно как микросервисы.) «И для этого мне понадобятся 50 лицензий на Windows, 30 лицензий на сервер приложения и как минимум 50 лицензий на сервер базы данных». В 2002 году попытка создания архитектуры, похожей на микросервисы, обошлась бы слишком дорого. А вот с появлением в последние годы открытого исходного кода в сочетании с новой революционной практикой разработки и сопровождения программных продуктов в рамках методологии DevOps построение именно такой архитектуры вполне оправданно. Читатели должны понимать, что все архитектуры являются продуктом конкретных обстоятельств.

Определение архитектуры программного обеспечения

Многие специалисты пытались дать точное определение понятию «архитектура программного обеспечения». Одни считали, что архитектура ПО является по своей сути неким планом системы, а другие определяли ее как дорожную карту разработки системы. Но эти общие определения не отвечали на вопрос о конкретном содержимом плана или карты. Например, что именно архитектор должен исследовать при анализе архитектуры?

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

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

Еще одним элементом определения архитектуры ПО являются ее свойства (рис. 1.4). Свойства архитектуры определяют критерии ее успеха, не имеющие ничего общего с функциональными возможностями системы. Заметьте, что все перечисленные свойства не требуют никаких сведений о функциональности системы и в то же время нужны для ее корректной работы. Свойства архитектуры играют настолько важную роль, что их определению и пониманию посвящено несколько глав этой книги.

Рис. 1.2. Архитектура состоит из структуры в сочетании со свойствами (выражаемыми словами с окончанием -ость), архитектурными решениями и принципами проектирования

Рис. 1.3. Под структурой подразумевается тип архитектурных стилей, используемых в системе

Рис. 1.4. Свойства архитектуры относятся к тому, что должно поддерживаться системой и описывается словами с окончанием -ость

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

Если из-за какого-то условия или другого ограничения конкретное архитектурное решение не может быть реализовано в одной из частей системы, это решение (или правило) может быть нарушено посредством так называемого отступления (variance). Модели отступлений, используемые наблюдательным советом за архитектурой (architecture review board, ARB) или главным архитектором, имеются в большинстве организаций. Эти модели определяют процесс поиска отступления от конкретного стандарта или архитектурного решения. Исключение из конкретного архитектурного решения анализируется советом ARB (или главным архитектором, если такого совета нет) и либо утверждается, либо отклоняется на основе обоснований и компромиссов.

Рис. 1.5. Архитектурные решения являются правилами построения систем

Рис. 1.6. Принципы проектирования являются руководящими установками выстраивания систем

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

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

Ожидания от работы архитектора

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

Независимо от каких-либо конкретных полномочий, титулов или должностных обязанностей, от архитектора ПО ожидается:

• принятие архитектурных решений;

• постоянный анализ архитектуры;

• своевременное следование последним тенденциям;

• контроль за выполнением принятых решений;

• обладание обширными знаниями и опытом;

• компетентность в нужной области бизнеса;

• владение навыками межличностного общения;

• четкое понимание политики компании.

Эффективная и плодотворная работа в должности архитектора программного обеспечения невозможна без понимания и осуществления каждого из этих ожиданий.

Принятие архитектурных решений

От архитектора ожидаются архитектурные решения и определение принципов проектирования, которые будут служить руководством для принятия технологических решений внутри команды, отдела или всего предприятия.

Ключевым здесь является слово руководство. Архитектор должен выдавать установки, а не определять выбор технологических решений. Например, архитектор может решить, что для разработки внешнего интерфейса нужно использовать библиотеку React.js. В этом случае он принимает техническое решение, а надо бы — архитектурное решение: определить принцип проектирования, помогающий команде разработчиков сделать свой выбор. Архитектор должен был бы рекомендовать команде разработчиков использовать для веб-разработки внешнего интерфейса реактивно-ориентированную среду и тем самым направить на выбор между Angular, Elm, React.js, Vue или любым другим фреймворком на реактивной основе.

Управлять выбором технологии через архитектурные решения и принципы проектирования довольно сложно. Ключом к принятию эффективных архитектурных решений является вопрос о том, помогает ли архитектурное решение направлять команды на выбор правильных технических решений или же такой выбор делается за них. И тем не менее бывает так, что для соблюдения конкретных архитектурных свойств, например масштабируемости, производительности или доступности, архитектору приходится принимать те или иные технологические решения. В таком случае это все равно будет ­считаться ­архитектурным решением, даже если им определяется конкретная технология. Архитекторы часто испытывают трудности с поиском правильного курса, поэтому архитектурным решениям целиком посвящена глава 19.

Постоянный анализ архитектуры

Архитектор должен постоянно анализировать архитектуру и текущую ­технологическую среду, а затем рекомендовать решения по их совершенствованию.

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

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

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

Своевременное следование последним тенденциям

Архитектор должен быть в курсе последних тенденций в технологии и в бизнес-секторе.

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

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

Контроль за выполнением принятых решений

Архитектор должен обеспечивать соответствие архитектурным решениям и принципам проектирования.

Контроль за выполнением принятых решений означает, что архитектор обязан постоянно проверять, что разработчики следуют принятым, задокументированным и доведенным до них архитектурным решениям и принципам проектирования. Рассмотрим такую ситуацию. Архитектор принял решение, что в многоуровневой архитектуре доступ к базе данных возможен только из бизнес- и сервис-уровня (и невозможен с уровня представления). Следовательно, даже для самых простых обращений к базе данных уровень представления должен пройти через все уровни архитектуры. Разработчик пользовательского интерфейса может не согласиться с этим и с целью повышения производительности обращаться к базе данных (или к уровню постоянного хранения данных) напрямую. Но архитектор принял данное архитектурное решение по конкретной причине: контроль изменений. Закрытие уровней позволяет вносить изменения в базу данных, не затрагивая уровень представления. Если не обеспечить соблюдение архитектурных решений, могут быть допущены такие нарушения, при которых архитектура перестанет отвечать требуемым свойствам (выражаемым словами с окончанием -ость), а приложение или система не будут работать так, как ожидалось.

В главе 6 мы подробнее поговорим об оценке соблюдения решений и принципов с помощью автоматизированных функций пригодности и соответствующих автоматизированных инструментов.

Обладание обширными знаниями и опытом

Ожидается, что архитектор обладает опытом работы с многочисленными и разнообразными технологиями, средами разработки, платформами и средами окружения.

Данное требование не означает, что архитектор должен быть великим знатоком каждой среды разработки, платформы и языка, скорее он должен быть знаком с различными технологиями. Большинство современных сред имеет неоднородный характер, и архитектор должен по крайней мере знать возможности взаимодействия нескольких систем и сервисов независимо от языков, платформ и технологий, использованных при написании таких систем или сервисов.

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

Компетентность в нужной области бизнеса

Ожидается, что архитектор достаточно хорошо ориентируется в нужной области бизнеса.

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

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

Владение навыками межличностного общения

Ожидается, что архитектор обладает навыками межличностного общения, включая работу в команде, содействие сотрудникам и лидерские качества.

Ожидать от большинства разработчиков и архитекторов наличия исключительных лидерских качеств и навыков межличностного общения довольно сложно. Обладая математическим мышлением, разработчики и архитекторы любят решать проблемы, связанные с техникой, а не с людьми. Однако, как говорил Джеральд Вайнберг (Gerald Weinberg): «Что бы они вам ни говорили, это всегда человеческая проблема». Предполагается, что архитектор не только обеспечит техническое руководство командой, но и будет руководить командой разработчиков в процессе реализации архитектуры. Лидерские качества — это как минимум половина того, чем должен обладать архитектор программного обеспечения независимо от его роли или должности.

В профессиональной среде много архитекторов ПО, которые сражаются за ограниченное число соответствующих вакансий. Наличие сильных лидерских качеств и развитых навыков межличностного общения — это то, что позволит архитектору выделиться из общей массы себе подобных. Мы встречали многих специалистов, которые были превосходными техническими экспертами, но никудышными архитекторами из-за неспособности руководить командами, обучать и наставлять разработчиков, а также успешно внедрять идеи, архитектурные решения и принципы. Излишне говорить, что таким архитекторам сложно сохранять за собой должность и работу.

Четкое понимание политики компании

Ожидается, что архитектор разбирается в политическом климате компании и умеет в нем ориентироваться.

Может показаться, что в книге, посвященной архитектуре программного обеспечения, обсуждение темы переговоров и ориентации в офисной политике выглядит как-то странно. Чтобы продемонстрировать важность и необходимость навыка ведения переговоров, рассмотрим ситуацию, в которой разработчик решает применить паттерн Стратегии ради сокращения общей цикломатической сложности конкретного фрагмента довольно непростого кода. Кого это действительно волнует? Можно было бы, конечно, поаплодировать за использование подобного паттерна, но почти во всех случаях разработчик не нуждается в одобрении такого решения.

А теперь рассмотрим другую ситуацию. Архитектор, отвечающий за крупную систему управления взаимоотношениями с клиентами (CRM), испытывает проблемы с управлением доступом к базе данных из других систем, защитой конкретных данных клиентов и внесением изменений в схему базы данных, поскольку база данных CRM используется слишком большим количеством других систем. Исходя из этого, архитектор принимает решение по созданию так называемого application silos, то есть хранилища, принадлежащего исключительно конкретному приложению. Получается, что каждая прикладная база данных доступна только из приложения, которому она принадлежит. Принятие такого решения позволит архитектору лучше контролировать клиентские данные, их безопасность и возможность их изменения. Но, в отличие от предыдущей ситуации с разработчиком, против этого решения будут практически все остальные сотрудники компании (за исключением, конечно, команды разработчиков CRM-приложения), ведь в данных управления взаимоотношениями с клиентами нуждаются и другие приложения. Если они больше не смогут обращаться к базе данных напрямую, то запрашивать эти данные придется у CRM-системы, для чего понадобятся вызовы через REST, SOAP или какой-либо иной протокол удаленного доступа.

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

Пересечение архитектуры и…

За последние десятилетия сфера применения архитектуры программного обес­печения расширилась и стала включать в себя больше ответственных задач и перспектив. Еще лет десять назад типичные отношения между архитектурой и функциональными аспектами носили договорной и формальный характер с множеством чисто бюрократических моментов. Большинство компаний, стараясь избежать сложностей, связанных с поддержкой собственных операций, зачастую прибегали к аутсорсингу. Они обращались к сторонним компаниям, у которых были договорные обязательства по соглашениям об уровне обслуживания, где прописывались время безотказной работы, масштаб, оперативность реагирования и масса других важных архитектурных свойств. Теперь такие архитектуры, как микросервисы, свободно используются для решения подобных эксплуатационных задач. Например, гибкое масштабирование когда-то встраивалось в архитектуры с великим трудом (см. главу 15), а микросервисы справляются с этим гораздо легче благодаря взаимодействию архитекторов и DevOps4.

История: Pets.com и почему у нас есть гибкое масштабирование

История разработки программного обеспечения насыщена как плохими, так и хорошими уроками. Мы думаем, что современные возможности (например, гибкое масштабирование) появились в один прекрасный день благодаря талантливому разработчику, но подобные идеи зачастую рождались из тяжелых уроков. История компании Pets.com — один из ранних примеров усвоения таких вот уроков. Pets.com появилась на заре интернета в надежде повторить успех Amazon.com в сфере продажи товаров для животных. Им повезло с отделом маркетинга, где собрались превосходные специалисты, придумавшие привлекательный талисман: надеваемую на руку куклу с микрофоном, говорившую всякие дерзости. Эта кукла стала суперзвездой, появляясь на публике на парадах и нацио­нальных спортивных мероприятиях.

К сожалению, руководство Pets.com, по-видимому, потратило все деньги на эту куклу, а не на инфраструктуру. Когда посыпались заказы, компания оказалась не готова к этому. Веб-сайт работал медленно, транзакции терялись, доставка задерживалась… то есть дела шли по наихудшему сценарию. Все было настолько плохо, что компания закрылась вскоре после рождественской торговой лихорадки, продав конкуренту единственный сохранивший ценность актив (ту самую куклу).

Компании явно не хватало гибкого масштабирования: возможности востребованного наращивания ресурсов. Поставщики облачных сервисов предоставляют масштабирование в виде стандартного свойства, но на заре интернета компаниям приходилось самим управлять своей инфраструктурой, и многие из них пали жертвой неслыханного ранее феномена: слишком большой успех способен убить бизнес. Трагедия Pets.com и другие подобные ужастики заставили специа­листов разработать фреймворки, которыми по сей день пользуются архитекторы.

В следующих разделах рассматривается ряд недавно возникших пересечений работы архитектора и других отделов организации, которые привели к возникновению новых возможностей и обязанностей.

Практика проектирования

Согласно сложившемуся порядку вещей, архитектура ПО была отделена от процесса разработки программного продукта. Известны десятки популярных методик создания программных продуктов, включая Waterfall и многие разновидности Agile (например, Scrum, Extreme Programming, Lean и Crystal ), которые, по большому счету, не оказывают на архитектуру ПО никакого влияния.

Но в последние несколько лет прогресс в области разработки программных средств заставил задуматься о процессах выстраивания архитектуры ПО. Появились причины отделить процесс разработки программного продукта от практики проектирования. Под процессом подразумевается формирование команд и управление ими, порядок проведения совещаний и организация повседневной работы, то есть все, что относится к специфике объединения людей и их взаимодействия. А под практикой проектирования ПО подразумевается деятельность, не связанная с процессом, но приносящая наглядную пользу. В качестве примера можно привести непрерывную интеграцию, которая не зависит от какого-либо конкретного процесса.

Сосредоточенность на практике проектирования играет весьма важную роль. Во-первых, разработка программных продуктов лишена многих свойств более зрелых инженерных дисциплин. Например, инженеры-строители могут предсказывать структурные изменения с гораздо большей точностью, чем аналогичные важные аспекты структуры ПО. Во-вторых, довольно важной проблемой разработки программных продуктов остается вычисление оценочных показателей: сколько уйдет времени, ресурсов, денег? Это связано с устаревшими методами оценки, которые не учитывают нужные показатели, а также с тем, что мы не можем оценить из-за неизвестных неизвестностей.

...Есть известные известные — вещи, о которых мы знаем, что знаем их. Есть также известные неизвестные — вещи, о которых мы знаем, что не знаем. Но еще есть неизвестные неизвестные — это вещи, о которых мы не знаем, что не знаем их.

Бывший министр обороны США Дональд Рамсфельд (Donald Rumsfeld)

Неизвестные неизвестности — это злейший враг программных систем. Многие проекты начинаются с перечня известных неизвестностей: тех особенностей, которые появятся в будущем в этой сфере и технологии и по этой причине должны быть изучены разработчиками. Но также проекты могут стать жертвами неизвестных неизвестностей, внезапного появления которых никто не мог предугадать. Именно из-за этого попытки разработать программное обеспечение «с большим заделом» («Big Design Up Front») оказываются неудачными: архитекторы не в состоянии проектировать с учетом неизвестных неизвестностей. Приведем цитату Марка (одного из авторов этой книги):

Разработка архитектуры стала итеративным процессом из-за неизвестных неизвестностей, но Agile просто признает это и делает это быстрее.

Путь от экстремального программирования к непрерывной Доставке

История возникновения экстремального программирования (Extreme Programming, XP)5 может послужить хорошей иллюстрацией отличия технологического процесса от проектирования. В начале 1990-х годов группа опытных разработчиков программного обеспечения под руководством Кента Бека (Kent Beck) начала проверять эффективность множества различных популярных в то время процессов разработки. Был сделан вывод, что ни один из них не добивается стабильно удачных результатов. Один из основателей XP как-то сказал, что при выборе одного из существующих процессов «успех проекта гарантировался не более, чем при подбрасывании монетки». Группа решила переосмыслить приемы создания программных продуктов и в марте 1996 года запустила проект XP. Они отказались от традиционных представлений и сконцентрировались на практических подходах, которые в прошлом приносили успех проектам, подняв их до «экстремального» уровня. Логика команды основывалась на наблюдаемой в предыдущих проектах взаимосвязи большего количества тестов и более высокого качества продукта. Таким образом, XP-подход к тестированию вывел проектирование на новый уровень: до проведения разработки, при которой тестирование выводится на первый план, гарантируя, что весь код будет протестирован до его попадания в кодовую базу.

XP-программирование было включено в список популярных Agile-процессов, но при этом относилось к тем немногочисленным методикам, которые включали в себя автоматизацию, тестирование, непрерывную интеграцию и другие четко выраженные и основанные на практическом опыте методы. Активное развитие разработки программного обеспечения началось с выходом обновленной версии многих практических приемов XP в книге «Continuous Delivery» (издательство Addison-Wesley Professional) и привело к появлению DevOps. Во многих отношениях DevOps-революция произошла в тот момент, когда был принят подход XP-программирования: автоматизация, тестирование, объявление единого источника достоверных данных и т.д.

Мы всецело поддерживаем достигнутый в этой области прогресс, выстраивающий поэтапные шаги, которые в конечном счете переведут разработку программного обеспечения в разряд полноценной проектной дисциплины.

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

Зачастую архитектор ПО также является техническим лидером разработчиков проекта и поэтому определяет стратегию проектирования, которой должна придерживаться команда. Это похоже на ситуацию, при которой архитектор строительства тщательно изучает проблемный георегион, прежде чем выбрать архитектурный стиль зданий. Он также следит за тем, чтобы архитектурный стиль и инженерные решения образовывали единую гармоничную систему. К примеру, архитектура микросервисов предполагает автоматизированное предоставление аппаратных ресурсов, автоматизированное тестирование и развертывание, а также целый ряд других возможностей. Попытка выстроить одну из таких архитектур с устаревшей структурой, ручными процессами и небольшим количеством тестов приводит к серьезным противоречиям и становится препятствием на пути к успеху. Методики проектирования должны быть подобраны в соответствии с правилами архитектуры, подобно тому как в проблемных регионах при строительстве зданий учитываются особенности окружающей среды.

Развитие мысли, позволившее пройти путь от экстремального программирования (XP) до непрерывной разработки (continuous delivery), продолжается. Последние достижения в практике проектирования открывают новые возможности в архитектуре. В книге Нила «Building Evolutionary Architectures»6 (издательство O’Reilly)7 раскрываются новые взгляды на пересечение методов проектирования и архитектуры, позволяющие улучшить автоматизацию управления архитектурой. Мы не будем приводить здесь краткое содержание этой книги, но отметим, что в ней представлен инновационный взгляд на концепцию свойств архитектуры, которые будут рассмотрены в оставшейся части нашей книги.

В книге Нила дается описание методов построения постепенно меняющихся архитектур. В главе 4 будет дано описание архитектуры в виде сочетания требований и дополнительных соображений, как показано на рис. 1.7.

Рис. 1.7. Архитектура программной системы содержит как требования, так и свойства архитектуры

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

В правилах построения эволюционных архитектур есть понятие функций пригодности (fitness functions). Они служат для защиты архитектурных свойств (и управления ими), когда с течением времени происходят различные изменения. Идея позаимствована из эволюционных вычислительных методов. Во время создания генетического алгоритма разработчики могут применять множество методов изменения (мутации) решения, итеративно подбирая новые варианты. При построении такого алгоритма для конкретной цели необходимо оценить итоговый результат, чтобы увидеть, насколько он близок или далек от оптимального решения; такая оценка и является функцией пригодности. Например, если разработчики создали наследственный алгоритм для решения известной задачи коммивояжера (нахождение кратчайшего маршрута между различными городами), то функция пригодности оценит протяженность маршрута.

В эволюционных архитектурах эту методику используют и для создания архитектурных функций пригодности, дающих объективную оценку целостности ряда архитектурных свойств. Эта оценка может включать в себя различные механизмы: например, системы показателей, юнит-тесты, системы отслеживания и хаос-инжиниринг. Скажем, в качестве важного архитектурного свойства архитектор задает время загрузки страницы. Чтобы позволить системе вносить изменения в страницу без ущерба для производительности, архитектурой создается функция пригодности в виде теста, замеряющего время загрузки для каждой страницы, а затем этот тест запускается для проекта как часть непрерывной интеграции. Благодаря этому архитекторы всегда в курсе состояния критически важных частей архитектуры, поскольку у них имеется механизм проверки для каждой такой части в форме функции пригодности.

Мы здесь не будем вдаваться в подробности функций пригодности, но будем указывать на возможности и примеры такого подхода там, где это уместно. Обратите внимание на взаимосвязь между частотой выполнения функций пригодности и обратной связью, которую они обеспечивают. Вы поймете, что практика проектирования с использованием таких Agile-технологий, как непрерывная интеграция, автоматизированное предоставление аппаратных ресурсов и т.д., существенно упрощает построение гибких архитектур. К тому же при этом наглядно демонстрируется, насколько тесно архитектура переплетается с методами проектирования.

Использование систем сопровождения или DevOps

С появлением методологии DevOps произошло наиболее очевидное пересечение архитектуры и смежных областей, вызванное некоторым переосмыслением архитектурных аксиом. Долгое время множество компаний рассматривали сопровождение готовой программы как отдельную процедуру, не имеющую ничего общего с разработкой ПО, поэтому часто в целях экономии средств сопровождение передавалось другой компании. Многие архитектуры, разработанные в 1990-е и 2000-е годы, выстраивались с предположением, что архитекторы не в состоянии контролировать процесс эксплуатации, и были созданы в расчете на строгую защиту данного ограничения (здесь хорошим примером может послужить пространственная архитектура Space-Based Architecture, которую мы рассмотрим в главе 15).

Но несколько лет назад ряд компаний начали экспериментировать с новыми формами архитектуры, где задачи поддержки были встроены в архитектуру. Например, в архитектурах старого стиля, таких как ESB-driven SOA, сама архитектура выстраивалась для гибкого масштабирования, что существенно усложняло ее. Архитекторы были вынуждены обходить ограничения, связанные с экономией средств при передаче сопровождения на ауторсинг. Поэтому создавались архитектуры, способные самостоятельно справляться с масштабированием, поддержкой высокой производительности и гибкости, а также обеспечивать ряд других возможностей. Но побочным эффектом такого подхода была сильно усложненная архитектура.

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

Процесс разработки

Еще одна аксиома гласит, что архитектура ПО по большей части не зависит от процесса разработки программ: способ создания программных продуктов (процесс) практически не влияет на архитектуру ПО (структуру). Это убеждение сохраняется даже в случае, если стиль проектирования, который выбрала команда, каким-то образом воздействует на архитектуру (особенно в части практики проектирования). Во многих книгах, посвященных архитектуре ПО, игнорируется сам процесс разработки, необоснованно считающийся предсказуемым. Однако процесс, с помощью которого команды разработчиков создают программное обеспечение, оказывает влияние на многие аспекты архитектуры. Например, за последние десятилетия множество компаний приняли методику разработки Agile из-за самой природы ПО. Архитекторы в Agile-проектах могут допустить поэтапную разработку и, следовательно, ускоренный цикл обратной связи для принятия решений. А это, в свою очередь, позволит архитекторам проявить настойчивость в проведении экспериментов и получении ценной информации, основанной на этой обратной связи.

Из предыдущей цитаты Марка следует, что рано или поздно к итеративной разработке придут все архитекторы. В связи с этим мы будем опираться на методологию Agile и указывать на исключения там, где это понадобится. Например, в отношении монолитных архитектур по-прежнему принято использовать устаревшие процессы разработки, что обусловливается их возрастом, политикой или иными факторами, не связанными с программным обеспечением.

Один из важнейших аспектов архитектуры, где наиболее ярко проявляются все преимущества Agile-методологии, — реструктуризация. У команд довольно часто возникают потребности в переносе своей архитектуры с одного паттерна на другой. К примеру, команда исходно полагалась на монолитную архитектуру, поскольку она проще и с нее быстрее начать, но по мере развития проекта им требуется переходить на более современную архитектуру. Такие изменения лучше поддерживаются не жестко распланированными процессами, а Agile-методами, которые обеспечивают сжатый цикл обратной связи и стимулируют применение таких технологий, как паттерн Душитель (Strangler Pattern) и переключатели функциональности.

Данные

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

Администраторы баз данных часто работают вместе с архитекторами над созданием архитектуры данных для сложных систем. Задача — проанализировать, как схема базы данных и многократное использование влияют на портфель приложений. Мы не будем углубляться в такие специализированные детали в этой книге. Но в то же время не станем игнорировать существование внешних хранилищ и зависимость от них. В частности, когда речь пойдет об эксплуатационных аспектах архитектуры и об архитектурных квантах (см. главу 3), мы обязательно коснемся таких важных внешних факторов, как базы данных.

Законы архитектуры программного обеспечения

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

Все в архитектуре программного обеспечения соткано из компромиссов.

Первый закон архитектуры программного обеспечения

Для архитекторов ПО не существует ничего заведомо удобного и понятного. Каждое решение исходит из учета множества противоречащих друг другу факторов.

Если архитектор полагает, что обнаружил нечто бескомпромиссное, то, скорее всего, компромисс еще просто не выявлен.

Следствие 1

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

Почему важнее, чем как.

Второй закон архитектуры программного обеспечения

Важность именно такого взгляда на вещи обнаружилась авторами при попытке сохранить результаты упражнений, выполненных студентами во время практического курса по принятию архитектурных решений. Поскольку на упражнения отводилось ограниченное время, мы сохранили только схемы, показывающие топологию. Иными словами, мы зафиксировали то, как решалась задача, но не почему командой выбирался тот или иной вариант. Архитектор может посмотреть на существующую систему, о которой он ничего не знает, и понять, как работает эта структура, но ему будет трудно объяснить, почему были выбраны эти, а не другие варианты.

В книге везде акцентируется внимание на том, почему архитекторы принимают те или иные решения наряду с компромиссами. Кроме того, в разделе главы 19 «Запись архитектурных решений» (на с. 332) мы обращаем внимание на полезные приемы фиксирования важных решений.

---

Часть I. Основы

Чтобы разобраться в важных компромиссах архитектуры, разработчики должны усвоить ряд основных понятий и терминов, относящихся к компонентам, модульности, связанности и коннасценции.

Глава 2. Архитектурное мышление

Архитектор смотрит на вещи совсем не так, как разработчик, аналогично тому как метеоролог смотрит на облака не так, как художник. Взгляд архитектора обусловлен архитектурным мышлением. К сожалению, слишком многие архитекторы считают, что архитектурное мышление — это просто «размышления об архитектуре» (рис. 2.1).

Рис. 2.1. Архитектурное мышление (iStockPhoto)

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

В этой главе будут исследованы все четыре особенности архитектурного мышле­ния и взгляд на вещи глазами архитектора.

Архитектура и проектирование

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

Рассмотрим изображенное на рис. 2.2 традиционное сравнение обязанностей архитектора с обязанностями разработчика. Согласно схеме, архитектор отвечает за анализ бизнес-требований, чтобы выявить и определить архитектурные свойства (выражаемые словами с окончанием на -ость); за выбор конкретных архитектурных паттернов и стилей, соответствующих задачам предметной области; и, наконец, за создание компонентов (строительных блоков системы). Затем все эти решения передаются команде разработчиков, отвечающей за создание диаграммы классов для каждого компонента, экранов пользовательского интерфейса, а также за разработку и тестирование исходного кода.

В традиционной модели ответственности, показанной на рис. 2.2, имеется целый ряд проблем. По сути, именно здесь и показано, почему архитектура редко работает так, как следует. Главной причиной всех проблем, связанных с архитектурой, является однонаправленная стрелка, что проходит через виртуальные и физические барьеры, отделяющие архитектора от разработчика. Решения, принимаемые архитектором, порой вообще не доходят до команд разработчиков, а решения команд разработчиков, изменяющие архитектуру, редко попадают в поле зрения архитектора. В этой модели архитектор не связан с командами разработчиков, поэтому архитектура редко достигает цели, ради которой она была создана.

Рис. 2.2. Традиционное сравнение выстраивания архитектуры и проектирования

Чтобы получить работоспособную архитектуру, следует разрушить все существующие физические и виртуальные барьеры между архитекторами и разработчиками, сформировав, таким образом, двунаправленные отношения. Рабочие отношения предполагают объединение архитектора и разработчика в одну виртуальную команду (рис. 2.3). Такая модель не только поможет созданию прочной двунаправленной связи между выстраиванием архитектуры и проектированием, но и позволит архитектору направлять и инструктировать команду разработчиков.

Рис. 2.3. Обеспечение работоспособности архитектуры за счет сотрудничества

В отличие от каскадных подходов старой школы, предполагающих статичную и неизменную архитектуру ПО, архитектура современных систем изменяется и совершенствуется с каждым этапом или фазой проекта. Тесное сотрудничество архитектора и команды разработчиков является залогом успеха любого программного проекта. А где же тогда заканчивается выстраивание архитектуры и начинается проектирование? Да нигде. И то и другое является частью жизненного цикла программного проекта, и для достижения успеха оба процесса должны всегда выполняться синхронно.

Широта технических взглядов

У разработчиков и архитекторов разные сферы охвата технологических деталей. В отличие от разработчика, который для выполнения своих задач обязан иметь весьма существенный объем глубоких технических знаний (техническую глубину), архитектор ПО должен обладать широтой технических взглядов (технической широтой, или техническим кругозором), чтобы мыслить как архитектор и смотреть на вещи с точки зрения архитектуры. Эти понятия иллюстрируются пирамидой, показанной на рис. 2.4, в которой заключены все технические знания в мире. Оказывается, вид информации, представляющей ценность для технического специалиста, меняется по мере его профессионального роста.

Рис. 2.4. Пирамида, представляющая весь объем знаний

На рис. 2.4 показано, что любой человек может разделить все свои знания на три части: на известные ему вещи, на неизвестные и на те вещи, о которых он не знает, что не знает их.

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

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

Расширение верхней части пирамиды выгодно, потому что опыт оценивается высоко (рис. 2.5). Но усвоенные знания также относятся к знаниям, требующим постоянной поддержки их актуальности, поскольку в мире программного обеспечения нет ничего статичного. Если разработчик становится знатоком Ruby on Rails, его квалификация будет утрачена, стоит только ему забросить Ruby on Rails на год-два. Нужно уделять достаточно времени, чтобы поддерживать актуальность знаний, показанных в верхней части пирамиды. По сути, размер верхней части чьей-то конкретной пирамиды отображает техническую глубину знаний данного специалиста.

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

Рис. 2.5. Для сохранения квалификации разработчики должны поддерживать актуальность своих знаний

Рис. 2.6. Объем усвоенных знаний представляет техническую глубину, а эрудиция — техническую широту

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

Рис. 2.7. Рост диапазона и уменьшение глубины знаний для соответствия роли архитектора

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

Архитекторам следует сосредоточиться на технической широте, чтобы у них был большой колчан, из которого можно будет извлекать стрелы. Разработчикам, выбившимся в архитекторы, возможно, придется изменить свое представление о получении знаний. На протяжении всей своей профессиональной деятельности каждый разработчик должен выдерживать тонко выверенный баланс глубины и широты своих знаний.

Антипаттерн Замороженный троглодит

Поведенческий антипаттерн Замороженный троглодит (Frozen Caveman), часто встречающийся на практике, описывает архитектора, который в каждой архитектуре неизменно возвращается к своим излюбленным, но уже ничем не обоснованным принципам. Например, один из коллег Нила разрабатывал систему с централизованной архитектурой. И неизменно при каждом представлении проекта архитекторы заказчика задавали вопрос: «А мы не потеряем Италию?». Несколько лет назад при весьма странных обстоятельствах пропала связь штаб-квартиры со своими магазинами в Италии, что вызвало ряд серьезных неудобств. Шансы на повторение инцидента были крайне малы, но архитекторы зациклились именно на этом свойстве архитектуры.

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

Анализ компромиссов

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

Архитектура — это то, что невозможно загуглить.

В архитектуре все соткано из компромиссов, поэтому известный ответ на каждый касающийся архитектуры вопрос будет звучать так: «Это с какой стороны посмотреть». Многих такой ответ раздражает, но, к сожалению, так оно и есть. В поисковике Google не найти ответа на вопросы: что будет лучше, REST или обмен сообщениями, или будут ли микросервисы верным архитектурным стилем. Все зависит от конкретных обстоятельств. От среды развертывания, бизнес-факторов, сложившейся в компании технической культуры, выделенного бюджета, установленных сроков, мастерства разработчиков и десятка других обстоятельств. У всех разные окружения, ситуации и задачи, именно поэтому выстраивание архитектуры — дело крайне трудное. Процитируем Нила (еще одного автора книги):

В архитектуре нет верных или неверных ответов, есть только компромиссы.

Рассмотрим, к примеру, систему аукционных торгов, показанную на рис. 2.8, где все предлагают свою цену за лот, выставленный на аукцион.

Рис. 2.8. Пример компромисса в аукционной системе: выбрать очереди или темы?

Сервис Bid Producer генерирует предложение цены от участника аукциона, после чего отправляет ее значение сервисам Bid Capture, Bid Tracking и Bid Analytics. Это можно сделать с помощью очередей в стиле обмена сообщениями «точка — точка» (point-to-point) или же воспользоваться темой (топиком, topic) в формате «публикация и подписка» (publish-and-subscribe). Каким вариантом воспользоваться архитектору? В Google ответа нет. Архитектурное мышление требует проанализировать компромиссы, связанные с каждым вариантом, и выбрать самый подходящий для конкретной ситуации.

На рис. 2.9 и 2.10 показаны два варианта обмена сообщениями для системы аукционных торгов. На первом рисунке — использование топика в модели «пуб­ликация и подписка», а на втором — использование очередей в модели обмена сообщений «точка — точка».

Рис. 2.9. И