Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
Новые инструменты, фреймворки методики и парадигмы вновь и вновь меняют экосистему разработки программного обеспечения. Непрерывный прогресс основных практик разработки на протяжении последних пяти лет заставил искать новые пути и подходы к архитектуре, чтобы соответствовать постоянно меняющимся требованиям пользователей. В обновленном издании авторы Нил Форд, Ребекка Парсонс, Патрик Куа и Прамод Садаладж приводят реальные примеры, соответствующие потребностям современной разработки ПО.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 302
Veröffentlichungsjahr: 2024
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Нил Форд, Ребекка Парсонс, Патрик Куа, Прамод Садаладж
Эволюционная архитектура. Автоматизированное управление программным обеспечением. 2-е межд. изд.. — Астана: "Спринт Бук", 2024.
ISBN 978-601-08-3643-3
© ТОО "Спринт Бук", 2024
Оглавление
Предисловие к первому изданию
Долгое время индустрия разработки программного обеспечения исходила из того, что архитектура продукта должна быть полностью сформирована до начала написания кода. По аналогии со строительной сферой успешной программной архитектурой считалась та, которую, подобно каркасу здания, не требовалось менять в процессе разработки: ошибки и изменения в прежние времена обходились дорого.
Эти представления были нарушены с появлением agile-подхода. Предварительное планирование архитектуры было основано на том, что требования также должны быть зафиксированы до начала написания кода, и этому принципу следовала поэтапная (или водопадная) разработка, когда вначале формулировались требования, затем создавалась архитектура, а потом начиналось строительство продукта (написание кода). Однако agile-методология поставила под сомнение само понятие фиксированных требований, декларируя, что в современном мире бизнесу необходимы регулярные изменения требований, и представила методы планирования проекта, поддерживающие внесение контролируемых изменений.
В современной agile-среде роль архитектуры часто подвергается сомнению. И, конечно, ее планирование не вписывается в новые динамичные условия. Но существует и другой подход к архитектуре, который приветствует адаптивные изменения. В рамках этого подхода архитектура выступает как сущность, требующая постоянного приложения усилий, связанных с написанием кода, чтобы реагировать как на изменение требований, так и на обратную связь, заложенную в коде. Мы назвали его эволюционной архитектурой, чтобы подчеркнуть, что, несмотря на то что изменения непредсказуемы, архитектура все равно может совершенствоваться в нужном направлении.
В Thoughtworks мы придерживаемся именно этого подхода. Ребекка в качестве технического директора компании руководила многими важнейшими проектами начала тысячелетия. Нил внимательно наблюдал за работой, обобщая полученные знания и передавая их другим. Патрик совмещал работу над проектами с развитием наших техлидов. Мы всегда считали архитектуру жизненно важной составляющей проекта, которую нельзя пускать на самотек. Мы делали ошибки, но учились на них, стараясь понять, как создавать кодовые базы, эффективно приспосабливающиеся к неоднократным изменениям своего назначения.
В основе эволюционной архитектуры лежат небольшие инкрементные изменения и циклы обратной связи, дающие возможность обучаться на том, как развивается система. Развитие непрерывной доставки стало толчком к практическому применению эволюционной архитектуры. Авторы используют концепцию фитнес-функции для мониторинга состояния архитектуры. Они исследуют различные стили эволюционной архитектуры и акцентируют внимание на вопросах, связанных с долго хранимыми данными — теме, которую часто обходят вниманием. Большинство утверждений, представленных здесь, как и следует ожидать, основано на законе Конвея.
Хотя я уверен, что нам еще многое предстоит узнать об эволюции программной архитектуры, эта книга аккумулирует все текущие представления об этом подходе. Поскольку все больше людей понимают, что в XXI веке центральную роль в нашем мире играют программные системы, любой лидер нашей отрасли просто обязан знать, как эффективно реагировать на изменения, не выпадая при этом из обоймы.
— Мартин Фаулер (Martin Fowler) martinfowler.com, сентябрь 2017 г.
Предисловие ко второму изданию
Прием метафоры основан на сравнении двух разнородных понятий, подчеркивающем их основные свойства. Хороший пример — программная архитектура. Обычно ее сравнивают со структурой здания. Структурные элементы здания: внешние и внутренние стены, крыша, площадь комнат, количество этажей, даже расположение здания — можно сопоставить со структурными элементами программной архитектуры: базами данных, сервисами, протоколами связи, интерфейсами, местом развертывания (в облаке или локально) и т.д. Прежде считалось, что в обоих случаях эти единожды созданные элементы в дальнейшем с трудом поддаются изменениям. И именно здесь метафора здания перестает работать.
Сегодня параллели со строительством уже не актуальны. Хотя объяснять человеку, далекому от сферы технологий, что такое программная архитектура, по-прежнему лучше всего в терминах сравнения структуры системы, программная архитектура должна быть способной к быстрым изменениям, в отличие от строительных конструкций. Почему же она должна быть такой податливой? Потому что современный бизнес находится в состоянии постоянных изменений — слияний, поглощений, открытия новых направлений, внедрения мер по сокращению расходов, новых организационных структур и т.д. Технологии тоже меняются, появляются новые фреймворки, технические среды, платформы и продукты. Чтобы соответствовать требованиям бизнеса и технологий, программная архитектура также должна меняться, причем такими же быстрыми темпами. Хороший пример — приобретение бизнеса крупной компанией. Помимо соответствия множеству новых бизнес-задач, архитектура основных бизнес-приложений должна быть способна масштабироваться, чтобы удовлетворить потребности увеличившейся клиентской базы, а также адаптироваться и расширяться, чтобы в нее можно было внедрить новые бизнес-функции и практики.
Многие компании знают об этом, но сталкиваются с проблемой: как сделать программную архитектуру достаточно гибкой, чтобы она выдерживала быстрые темпы изменения бизнеса и технологий? Ответ на этот вопрос дан в книге, которую вы держите в руках. Второе издание опирается на концепции управляемых инкрементных изменений, представленные в первом издании, и делится новейшими методами, знаниями и советами, касающимися фитнес-функций, автоматизации управления архитектурой и эволюционных данных. Применяя их, вы обеспечите гибкость архитектуры, достаточную, чтобы соответствовать непрерывным изменениям современного мира.
— Марк Ричардс (Mark Richards) developertoarchitect.com, октябрь 2022 г.
Введение
Когда в 2017 году мы работали над первым изданием этой книги, идея эволюционной программной архитектуры все еще казалась довольно радикальной. Во время одной из первых презентаций на эту тему Ребекку даже обвинили в непрофессионализме, поскольку она озвучила предположение, что программная архитектура способна развиваться с течением времени, — ведь считалось, что архитектура никогда не меняется.
Реальность учит нас, что системы должны развиваться, чтобы соответствовать новым требованиям пользователей и постоянно меняющейся экосистеме разработки.
На момент публикации первого издания существовало еще мало инструментов, подходящих для реализации описанных нами методов. К счастью, разработка программного обеспечения продолжает развиваться, и появляются все новые решения, облегчающие создание эволюционных архитектур.
Структура книги
Мы изменили структуру по сравнению с первым изданием, четко разграничив две основные темы: инженерные практики создания эволюционных программных систем и структурные подходы, которые облегчают этот процесс.
В первой части мы рассматриваем механизмы и практики разработки, подходящие для реализации эволюционной архитектуры, в том числе методы, инструменты, категории и все, что необходимо читателям для понимания этой темы.
Программная архитектура также включает проектирование структур, и существуют решения, которые облегчают их эволюцию (и управление ими). Мы расскажем об этом в части II, которая, кроме того, включает обзор стилей архитектуры, а также принципов проектирования, основанных на связанности, повторном использовании и других важных структурных соображениях.
В программной архитектуре практически не существует изолированных элементов; многие принципы и практики эволюционной архитектуры предполагают комплексное взаимодействие составляющих процесса разработки, о чем мы расскажем в части III.
Практические примеры и PenultimateWidgets
В книге разбираются практические примеры. На момент работы над материалом все авторы занимались (а некоторые до сих пор занимаются) консультированием, и многие примеры, которые здесь представлены, основаны на их реальном опыте. Хотя мы не могли разглашать конфиденциальные детали, мы все же хотели разобрать несколько подходящих ситуаций, чтобы не ограничиваться абстрактной теорией. Так родилась вымышленная компания PenultimateWidgets, в которой происходят все рассматриваемые ситуации.
При поготовке второго издания мы попросили коллег привести еще более наглядные примеры применения обсуждаемых методов. Каждый такой кейс в книге представлен как случай из практики PenultimateWidgets, но все они взяты из реальных проектов.
Условные обозначения
В этой книге используются следующие условные обозначения:
Курсив
Курсивом выделены новые термины или важные понятия.
Моноширинный шрифт
Используется для листингов программ, а также внутри абзацев для обозначения таких элементов, как переменные и функции, базы данных, типы данных, переменные среды, операторы и ключевые слова.
Моноширинный полужирный шрифт
Используется для команд или другого текста, который пользователь должен ввести самостоятельно.
Моноширинный курсив
Используется для текста, который должен быть заменен значениями, введенными пользователем, или значениями, определяемыми контекстом.
Шрифт без засечек
Используется для обозначения URL, адресов электронной почты, названий кнопок и других элементов интерфейса, имен файлов и каталогов.
Этот рисунок указывает на совет или предложение.
Этот рисунок указывает на общее примечание.
Этот рисунок указывает на предупреждение.
Использование исходного кода примеров
Вспомогательные материалы (примеры кода, упражнения и т.д.) доступны для загрузки по адресу http://evolutionaryarchitecture.com.
Если у вас возникнут вопросы технического характера по использованию примеров кода, направляйте их по электронной почте на адрес [email protected].
В общем случае все примеры кода из книги вы можете использовать в своих программах и в документации. Вам не нужно обращаться в издательство за разрешением, если вы не собираетесь воспроизводить существенные части программного кода. Если вы разрабатываете программу и используете в ней несколько фрагментов кода из книги, вам не нужно обращаться за разрешением. Но для продажи или распространения примеров из книги вам потребуется разрешение от издательства O’Reilly. Вы можете отвечать на вопросы, цитируя данную книгу или примеры из нее, но для включения существенных объемов программного кода из книги в документацию вашего продукта потребуется разрешение.
Мы рекомендуем, но не требуем добавлять ссылку на первоисточник при цитировании. Под ссылкой на первоисточник мы подразумеваем указание авторов, издательства и ISBN. Например: «Эволюционная архитектура», 2-е издание, Нил Форд, Ребекка Парсонс, Патрик Куа и Прамод Садаладж (O'Reilly). Авторское право Neal Ford, Rebecca Parsons, Patrick Kua, and Pramod Sadalage, 2023; 978-1-492-09754-9».
За получением разрешения на использование значительных объемов программного кода из книги обращайтесь по адресу [email protected].
Благодарности
Авторы выражают огромную благодарность коллегам, которые давали подсказки и помогали найти вдохновение для многих примеров фитнес-функций, представленных в этой книге. Мы говорим спасибо (порядок имен не имеет значения) Карлу Найгарду, Александру Гедерту, Сантошкумару Паланисами, Рави Кумару Пасумарти, Индхумати В., Маноджу Б. Нараянану, Нираджу Сингху, Сирише К., Гирешу Чунчуле, Мадху Дхарваду, Венкату В., Абдулу Джелани, Сентхилу Кумару Муругешу, Мэтту Ньюману, Сяоджуну Рену, Арчане Ханал, Хайко Герину, Слину Кастро, Фернандо Тамайо, Ане Родриго, Питеру Гиллард-Моссу, Анике Вайс, Биджешу Виджаяну, Назнин Рупавалле, Кавите Миттал, Вишванату Р., Дхивье Садасивам, Рози Тейшейре, Грегорио Мело, Аманде Маттос (Carl Nygard, Alexander Goedert, Santhoshkumar Palanisamy, Ravi Kumar Pasumarthy, Indhumathi V., Manoj B. Narayanan, Neeraj Singh, Sirisha K., Gireesh Chunchula, Madhu Dharwad, Venkat V., Abdul Jeelani, Senthil Kumar Murugesh, Matt Newman, Xiaojun Ren, Archana Khanal, Heiko Gerin, Slin Castro, Fernando Tamayo, Ana Rodrigo, Peter Gillard-Moss, Anika Weiss, Bijesh Vijayan, Nazneen Rupawalla, Kavita Mittal, Viswanath R., Dhivya Sadasivam, Rosi Teixeira, Gregorio Melo, Amanda Mattos) и всем, кого мы не назвали.
Нил благодарит всех участников конференций, где он выступал в течение последних нескольких лет, помогавших оттачивать и пересматривать необходимые знания лично и особенно онлайн, в связи с глобальной пандемией. Спасибо всем сотрудникам первой линии, которые активно помогали авторам в это трудное время. Он также благодарит технических рецензентов, предоставившиих ценные отзывы и советы. Кроме того, Нил благодарит своих кошек — Амадея, Фаучи и Линду Рут — за то, что отвлекали его и тем самым помогали находить новые идеи. Кошки никогда не думают о прошлом или будущем; они всегда в настоящем, поэтому время, проведенное с ними, ценно как возможность ощутить себя здесь и сейчас. Спасибо также нашему соседскому «коктейльному клубу», который задумывался как предлог повидаться с друзьями, а превратился в мозговой центр, объединивший соседей. И наконец, Нил благодарит свою бесконечно терпеливую жену, которая с улыбкой переживала сначала его командировки, а затем их внезапное отсутствие и другие неудобства, связанные с его работой.
Ребекка благодарит всех коллег, участников конференций, спикеров и авторов, которые на протяжении ряда лет предлагали идеи, инструменты и методы и подогревали интерес к эволюционной архитектуре. Она присоединяется к словам благодарности Нила в адрес научных редакторов за их внимание к деталям и комментарии. Кроме того, Ребекка благодарит соавторов за познавательные беседы и обсуждения во время совместной работы над книгой. Особую благодарность она выражает Нилу за выдающуюся дискуссию или даже спор, который они вели несколько лет назад по поводу различий эмерджентной и эволюционной архитектур. С тех пор эти идеи прошли долгий путь.
Патрик благодарит всех своих коллег и клиентов в ThoughtWorks, которые помогли понять необходимость эволюционной архитектуры и испытать ее идеи на практике. Он также присоединяется к словам благодарности Нила и Ребекки в адрес научных редакторов, чьи отзывы очень помогли улучшить книгу. Наконец, он благодарит соавторов за проведенные вместе последние несколько лет и за возможность тесного сотрудничества, невзирая на разницу в часовых поясах и перелеты, из-за которых личные встречи были редкостью.
Прамод благодарит всех коллег и клиентов, которые служили источником вдохновения для изучения и продвижения новых идей и мышления. Он благодарит соавторов за содержательные обсуждения всех аспектов архитектуры. Он также благодарит рецензентов — Кассандру Шум (Cassandra Shum), Генри Матчена (Henry Matchen), Луку Меццалиру (Luca Mezzalira), Фила Мессенджера (Phil Messenger), Владика Кононова, Венката Субраманиума (Venkat Subramanium) и Мартина Фаулера — за вдумчивые комментарии, которые очень помогли авторам. И наконец, он благодарит своих дочерей, Арулу и Архану, за радость, которую они приносят в его жизнь, и свою жену Рупали за любовь и поддержку.
О научном редакторе русского издания
Анна Белых — старший инженер-разработчик в компании КРОК. Участвовала в проектировании и разработке высоконагруженных информационных систем разных масштабов и с применением различных архитектурных решений. Также занималась вопросами производительности серверной (бэкенд) части информационных систем.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «SprintBook», компьютерная редакция).
Мы выражаем огромную благодарность компании «КРОК» за помощь в работе над русскоязычным изданием книги и их вклад в повышение качества переводной литературы.
Мы будем рады узнать ваше мнение!
Часть I. Механика
Эволюционная архитектура включает две обширные области: механику и структуру.
Механика эволюционной архитектуры описывает инженерные практики и методы проверки, благодаря которым архитектура и эволюционирует, и в этом она пересекается с управлением архитектурой. Механика включает инженерные практики, тестирование, метрики и т.д. — все, что делает возможным эволюцию программного обеспечения. В части I дается определение и приводятся многочисленные примеры механики эволюционной архитектуры.
Вторая область эволюционной архитектуры — структура или топология программных систем. Действительно ли определенные стили архитектуры больше подходят для создания систем, которым проще эволюционировать? Существуют ли структурные решения в архитектуре, которых следует избегать, чтобы облегчить эволюцию? Мы ответим на эти и другие вопросы в части II, посвященной структурированию архитектуры, способной эволюционировать.
Многие принципы построения эволюционных архитектур сочетают в себе вопросы механики и структуры; часть III книги называется «Влияние». Она содержит множество практических примеров, дает советы, рассказывает о паттернах и антипаттернах, а также обо всем, что необходимо знать архитекторам и командам, чтобы создавать эволюционирующие системы.
Глава 1. Архитектура эволюционных систем
Одна из актуальных задач разработки в целом и программной архитектуры в частности — создание систем, которые с возрастом не теряют своей привлекательности и эффективности. В этой книге рассматриваются два фундаментальных аспекта создания эволюционного ПО: использование эффективных инженерных практик agile-разработки и структурирование архитектуры для облегчения управления и внедрения изменений.
Читатели получат представление о том, насколько успешной является стратегия детерминированного управления изменениями архитектуры, когда существующее стремление обеспечить защиту ее характеристик объединяется с практическими методами, чтобы иметь возможность более эффективно изменять архитектуру, не нарушая ее.
Сложности создания эволюционных систем
Деградация данных (bit rot), также известная как гниение данных, гниение бит, ветшание данных, распад бит или энтропия программного обеспечения, — это постепенное ухудшение качества программного продукта с течением времени или снижение его отзывчивости, что в конечном итоге приводит к сбоям программы.
Разработчики уже давно бьются над созданием таких программных продуктов, которое не теряли бысвоего качества стечением времени. О том, насколько сложна эта задача, свидетельствуют многочисленные профессиональные поговорки и выражения, в том числе разнообразие синонимов bit rot, приведенных выше. По крайней мере два фактора определяют эту борьбу: проблема контроля всех подвижных частей сложного программного продукта и динамичный характер экосистемы разработки ПО.
Современные программы состоят из тысяч или даже миллионов частей, которые можно изменять по ряду параметров. И каждое из этих изменений имеет предсказуемые, а иногда и непредсказуемые последствия. Команды, которые пытаются управлять ими вручную, в конечном итоге не справляются с огромным количеством деталей и побочными эффектами от массы их возможных комбинаций.
Управлять многочисленными взаимодействиями программного обеспечения было бы довольно сложно в статичном контексте, но такого контекста не существует. Экосистема разработки программного обеспечения включает все инструменты, фреймворки, библиотеки и лучшие практики — весь накопленный багаж возможностей разработки на любой момент времени. Эта экосистема обладает равновесием, во многом похожим на равновесие биологических систем, которое разработчики могут исследовать и в рамках которого могут создавать продукты. Однако это равновесие динамично — постоянно появляется что-то новое, что нарушает баланс, пока не возникнет новое равновесие. Представьте себе курьера на моноколесе, везущего коробки: динамика — потому что курьер постоянно приспосабливается, чтобы оставаться в вертикальном положении, и равновесие — потому что он постоянно поддерживает баланс. В экосистеме разработки каждая новая инновация или практика может нарушить статус-кво, устанавливая новое равновесие. Образно выражаясь, мы продолжаем нагружать курьера на моноколесе новыми коробками, заставляя его заново искать равновесие.
Во многих отношениях архитекторы напоминают незадачливого курьера, постоянно балансирующего и адаптирующегося к меняющимся условиям. Инженерная практика непрерывной доставки (Continuous Delivery) представляет собой такой тектонический сдвиг равновесия: включение ранее изолированных функций, таких как операции, в жизненный цикл разработки ПО позволило переоценить значение изменений. Для создания систем предприятий больше не подходят статичные пятилетние планы, поскольку за этот срок вся вселенная разработки изменится, что сделает каждое долгосрочное решение потенциально бессмысленным.
Прорывные изменения трудно предсказать даже опытным специалистам. Распространение контейнеров с помощью таких инструментов, как Docker (https://www.docker.com/), — пример непредсказуемого изменения в отрасли. Однако мы можем проследить постепенное развитие контейнеризации. Когда-то операционные системы, серверы приложений и остальная инфраструктура представляли собой коммерческие объекты, требующие лицензирования и больших затрат. Многие архитектуры, разработанные в ту эпоху, были нацелены на эффективное совместное использование ресурсов. Постепенно ОС Linux стала приемлемой альтернативой для многих предприятий, что свело денежные затраты на операционные системы к нулю. Затем внедрение DevOps-практики автоматического выделения ресурсов машин с помощью таких инструментов, как Puppet (https://puppet.com/) и Chef (https://www.chef.io/), сделала Linux операционно свободной. Когда экосистема стала свободной и широко используемой, оказалась неизбежной консолидация вокруг общих переносимых форматов: так появился Docker. Но контейнеризация была бы невозможна без поэтапной эволюции, результатом которой она и явилась.
Экосистема разработки ПО постоянно развивается, что приводит к появлению новых архитектурных подходов. Хотя многие разработчики считают, что решение о том, каким будет следующий технологический прорыв, принимается тайным обществом архитекторов на своих собраниях в башне из слоновой кости, на самом деле этот процесс гораздо более органичен. В экосистеме постоянно возникают новые функции, которые можно по-новому комбинировать с уже существующими и с другими новыми функциями для реализации возможностей. Например, рассмотрим недавний бум архитектур микросервисов. По мере роста популярности ОС с открытым исходным кодом в сочетании с непрерывной доставкой сообразительные архитекторы придумали, как создавать более масштабируемые системы, и для этих систем понадобилось название: так появились микросервисы.
Почему в 2000 году не было микросервисов
Представьте архитектора с машиной времени, который отправляется в 2000 год и обращается к операционному директору с новой идеей.
«У меня есть отличная новая концепция архитектуры, которая обеспечивает небывалую изоляцию каждой функции — это называется микросервисы; мы разработаем каждый сервис на основе бизнес-возможностей и сохраним слабую связанность».
«Отлично, — говорит директор по операциям. — Что вам для этого нужно?»
«Ну, мне понадобится примерно 50 новых компьютеров, и, конечно, 50 лицензий на новые операционки, и еще 20 компьютеров для изолированных баз данных и лицензии на них. Когда я смогу все это получить?»
«Уходите».
Хотя уже тогда микросервисы могли казаться хорошей идеей, экосистема для их поддержки отсутствовала.
Часть работы архитектора заключается в структурном проектировании решений конкретных проблем — у вас есть проблема, и вы решили, что с ней справится программа. Структурное проектирование можно разделить на две области: предметная область (или требования) и характеристики архитектуры1, как показано на рис. 1.1.
Рис. 1.1. Программная архитектура включает в себя характеристики (всевозможные понятия, заканчивающиеся на «-ость») и требования
Требования, показанные на рис. 1.1, относятся к целевой предметной области программного решения. Другие части известны как характеристики архитектуры (предпочтительный термин), нефункциональные требования, атрибуты качества системы, сквозные требования и т.д. и т.п. Независимо от названия, они представляют собой свойства, необходимые для успеха проекта — как первоначального релиза, так и долгосрочно поддерживаемого продукта. Например, такие характеристики архитектуры, как масштабируемость и производительность, имеют значение для успеха продукта на рынке, а другие, такие как модульность, способствуют удобству обслуживания системыи ее способности эволюционировать.
Синонимы термина «характеристики архитектуры»
В книге мы используем термин «характеристики архитектуры» для обозначения аспектов проектирования, не относящихся к предметной области. Однако во многих организациях приняты другие термины для обозначения этой концепции, в том числе «нефункциональные требования», «сквозные требования» и «атрибуты качества системы». Мы не настаиваем на выбранной терминологии — используйте свой привычный термин, если вам удобно. Это синонимичные понятия.
Программы редко бывают статичными; они продолжают развиваться по мере того, как разработчики добавляют новые функции, точки интеграции и другие изменения. Архитекторам нужны механизмы защиты характеристик архитектуры наподобие модульных тестов, сфокусированных на характеристиках архитектуры, меняющихся с разной скоростью и иногда подверженных влиянию факторов, не связанных с предметной областью. Например, изменение базы данных может быть обусловлено выбором общих технических решений, внедряемых в компании, и не зависеть от решения для конкретной предметной области.
В этой книге описываются механизмы и методы проектирования, с которыми вы будете так же уверенно управлять архитектурой, как высокоэффективные команды управляют другими аспектами процесса разработки.
Архитектурные решения — это решения, подразумевающие наличие серьезных компромиссов для каждого возможного варианта. Для целей этой книги архитекторами мы называем всех, кто принимает архитектурные решения, независимо от их должности в организации. Кроме того, важные архитектурные решения практически всегда требуют взаимодействия с другими сотрудниками.
Нужна ли архитектура agile-проектам?
Это популярный вопрос, который задают те, кто уже какое-то время работает по принципам agile. Agile-методология призвана избавиться от бесполезных накладных расходов, что не всегда означает отказ от каких-то шагов, например от проектирования. Как часто бывает в архитектуре, масштаб диктует ее уровень. Сравните со строительством: если мы строим собачью будку, нам не нужна сложная архитектура; нам нужны только материалы. Но если мы строим 50-этажное офисное здание, нам необходим проект. Точно так же, если мы разрабатываем сайт с простой базой данных, нам не нужна архитектура; мы можем собрать его из доступных компонентов. Однако чтобы спроектировать высокомасштабируемый и общедоступный веб-сайт, например для массовой продажи билетов на мероприятия, мы должны тщательно продумать множество компромиссов.
Вместо вопроса «Нужна ли архитектура agile-проектам?», архитекторам нужно задать другой вопрос: при каком минимальном объеме необязательного проектирования они сохранят способность итерировать первоначальную версию проекта, чтобы создавать на ее основе более подходящие решения.
Эволюционная архитектура
Как механизмы эволюции, так и решения, которые принимают архитекторы при разработке программного обеспечения, основываются на следующем тезисе:
Эволюционная архитектура ПО поддерживает управляемые и инкрементные изменения в разных измерениях.
Он включает три характеристики, которые мы более подробно рассмотрим ниже.
Управляемые изменения
Определив ключевые характеристики, команда должна управлять изменениями в архитектуре, чтобы они соответствовали этим характеристикам. Для этого мы заимствуем концепцию из области эволюционных вычислений, называемую фитнес-функцией (fitness function),или иначе функцией пригодности (приспособленности). Фитнес-функция — это объективная функция, используемая для оценки того, насколько разрабатываемое решение достигает поставленных целей. В эволюционных вычислениях она определяет, становится ли алгоритм совершеннее со временем. Другими словами, по мере создания каждого варианта алгоритма функция пригодности определяет, насколько «пригодным» является этот вариант, основываясь на определении «пригодности» разработчиком.
В эволюционной архитектуре мы преследуем аналогичную цель: по мере развития архитектуры нам требуются механизмы, позволяющие оценить, как изменения влияют на важные характеристики архитектуры, и предотвратить ухудшение этих характеристик с течением времени. Подобие фитнес-функции охватывает множество механизмов, которые мы используем для предотвращения нежелательных изменений архитектуры, включая метрики, тесты и прочие инструменты проверки. Когда архитектор выделяет ту или иную характеристику архитектуры, которую он собирается защитить, он определяет одну или несколько функций пригодности для защиты этой характеристики.
Традиционно архитектура рассматривалась с позиции управления, и лишь с недавних пор архитекторы свыклись с возможностью внесения изменений в архитектуру. Фитнес-функции архитектуры позволяют принимать решения в контексте потребностей организации и задач бизнеса на видимой и проверяемой основе. Эволюционная архитектура не подразумевает разработку без ограничений и ответственности. Скорее это подход, который уравновешивает необходимость быстрых изменений и строгого соблюдения системных и архитектурных характеристик. Функция пригодности управляет принятием архитектурных решений, направляя архитектуру и позволяя вносить изменения, необходимые для поддержки меняющейся бизнес- и технологической среды.
Мы используем фитнес-функции как руководство по эволюции архитектур; подробно мы рассмотрим их в главе 2.
Инкрементные изменения
Определение инкрементные относится к двум аспектам программной архитектуры: созданию и развертыванию программных продуктов.
Что касается создания, то архитектуру, допускающую небольшие, постепенные изменения, легче усовершенствовать, поскольку разработчики могут вносить изменения меньшего масштаба. В части же развертывания инкрементные изменения относятся к уровню модульности и ослаблению сцепления бизнес-функций и к способам их выражения в архитектуре. Приведем пример.
Предположим, что у PenultimateWidgets, крупного продавца разных безделушек, есть каталог продуктов, созданный на основе микросервисной архитектуры и поддерживающий современные практики разработки. Одна из функций каталога позволяет пользователям оценивать продукты, ставя им звезды. Звездами можно оценивать и работу других сервисов PenultimateWidgets (службы поддержки клиентов, службы доставки и т.д.). Однажды команда разработчиков функции звездного рейтинга выпускает новую версию наряду с существующей, и теперь можно ставить ползвезды — небольшое, но важное улучшение. Остальные сервисы, использующие систему оценки, не обязаны переходить на новую версию, но могут постепенно мигрировать на нее в удобном для себя режиме. В DevOps-практику PenultimateWidgets входит архитектурный мониторинг не только сервисов, но и связей между ними. Когда группа эксплуатации замечает, что в течение определенного времени обращения к какому-то сервису отсутствуют, она автоматически исключает этот сервис из экосистемы.
Это пример инкрементных изменений на архитектурном уровне: исходный сервис может работать рядом с новым до тех пор, пока он нужен другим сервисам. Команды могут мигрировать к новым паттернам в удобном для себя ритме (или по мере необходимости), а старая версия автоматически становится мусором.
Чтобы инкрементные изменения были успешными, требуется совместное использование нескольких методов Continuous Delivery. Не всегда обязательно использовать все эти методы; скорее, они обычно естественным образом встречаются вместе. О том, как внедрять инкрементные изменения, мы поговорим в главе 3.
Разные измерения архитектуры
Отдельных, изолированных систем не существует. Мир непрерывен. Где провести искусственную границу вокруг системы, зависит от того, какая перед нами цель — на какие вопросы надо найти ответ.
— Донелла Х. Медоуз (Donella H. Meadows)
Древние греки учились анализировать Вселенную на основе неподвижных точек, в результате чего появилась классическая механика. Однако более точные приборы и более сложные явления сделали возможным развитие в начале ХХ века теории относительности. Ученые поняли, что явления, которые они раньше считали изолированными, на самом деле взаимосвязаны. С 1990-х годов продвинутые архитекторы все чаще рассматривают программную архитектуру как многомерную. Непрерывная доставка расширила эти представления, включив в них и операции. Однако программные архитекторы обычно ограничиваются технической архитектурой — тем, как компоненты программного обеспечения сочетаются друг с другом. Но это лишь одно измерение программного проекта. Если архитектор хочет создать архитектуру, которая способна развиваться, он должен учитывать все взаимосвязанные части системы, на которые влияют изменения. Как мы знаем из физики, что все относительно, так и архитекторы знают, что программный проект имеет несколько измерений.
Для создания программных систем, способных эволюционировать, архитекторы должны думать не только о технической архитектуре. Например, если проект включает реляционную базу данных, то структура и отношения между объектами базы данных также будут эволюционировать со временем. Точно так же не стоит создавать систему, в которой в результате развития возникнет уязвимость безопасности. Все это примеры измерений (dimensions)архитектуры — ее частей, которые сочетаются друг с другом, обычно пересекаясь. Некоторые измерения вписываются в понятие характеристикиархитектуры (те самые слова на «-ость», о которых мы уже говорили), но измерения на самом деле шире и охватывают понятия, традиционно выходящие за рамки технической архитектуры. Каждый проект имеет свои измерения, которые архитектор должен учитывать, думая об эволюции. Вот некоторые общие измерения, которые влияют на возможность эволюции в современных программных архитектурах.
Техническое измерение
Реализационные части архитектуры: фреймворки, зависимые библиотеки и язык(и) реализации.
Данные
Схемы баз данных, компоновка таблиц, планирование оптимизации и т.д. Обычно это зона ответственности администратора базы данных.
Безопасность
Политики и рекомендации по безопасности и инструменты для выявления недостатков.
Операционное/системное измерение
Как архитектура соотносится с существующей физической и/или виртуальной инфраструктурой: серверами, кластерами машин, коммутаторами, облачными ресурсами и т.д.
Каждое из этих представлений формирует измерение архитектуры — целенаправленно выделенные части, поддерживающие определенное представление. Наша концепция архитектурных измерений включает в себя традиционные архитектурные характеристики («-ости»), а также любые другие функции, применяемые для создания программного продукта. Каждая из них формирует архитектурное представление, которое нам необходимо сохранять по мере эволюции предметной области и изменения условий среды.
Мысля в терминах архитектурных измерений, архитектор получает возможность проводить анализ способности различных архитектур эволюционировать; этот анализ основан на оценке того, как каждое важное измерение реагирует на изменения. Поскольку системы со временем все теснее связываются со вступающими друг с другом в противоречие зонами ответственности (масштабируемость, безопасность, распределение, транзакции и т.д.), архитекторы должны отслеживать в проектах больше измерений. Чтобы построить систему, способную эволюционировать, архитекторы должны учесть пути ее эволюции по всем ключевым измерениям.
Архитектурная часть проекта включает требования к программному продукту и другие измерения. Для защиты этих характеристик по мере эволюции архитектуры и экосистемы во времени можно использовать фитнес-функции, как показано на рис. 1.2.
Рис. 1.2. Архитектура включает требования и другие измерения, каждое из которых защищено фитнес-функциями
На рис. 1.2 проверяемость, данные, безопасность, производительность, допустимость и масштабируемость выделены как характеристики архитектуры, важные для разрабатываемого приложения. Поскольку бизнес-требования со временем меняются, каждая из характеристик использует фитнес-функции для защиты своей целостности.
Хотя мы подчеркиваем важность целостного взгляда на архитектуру, мы также понимаем, что значительная часть эволюционирующей архитектуры относится к техническим паттернам и примыкающим к ним темам, таким как связанность, или сцепление (coupling), и связность (cohesion)2. В главе 5 мы обсудим, как связанность технической архитектуры влияет на ее способность эволюционировать, а в главе 6 рассмотрим влияние связанности данных.
Связанность относится не только к структурным элементам программных проектов. Многие компании-разработчики недавно обнаружили, что на архитектуру продукта удивительным образом влияет структура команды. Обычно мы говорим о связанности применительно к разрабатываемым продуктам, но влияние команды ощущается уже на ранних этапах разработки и весьма часто, поэтому мы обсудим и эту тему.
Эволюция архитектуры помогает ответить на два вопроса, часто возникающих у архитекторов, работающих в современной экосистеме: Как осуществлять долгосрочное планирование, если все постоянно меняется? и Как, построив архитектуру, предотвратить постепенное ухудшение ее качества? Рассмотрим эти вопросы более подробно.
Как осуществлять долгосрочное планирование, если все постоянно меняется?
Платформы разработки, которые мы используем, — пример постоянной эволюции. С появлением новых версий языков программирования совершенствуются API, повышается их гибкость и применимость; новые языки предлагают новую парадигму и новые наборы конструкций. Например, Java позиционировался как замена C++, облегчающая написание кода и управление памятью. Если взглянуть на то, что происходило последние 20 лет, можно заметить, что многие языки по-прежнему постоянно развивают свои API, в то время как для решения новых проблем появляются совершенно новые языки. Эволюция языков программирования показана на рис. 1.3.
Рис. 1.3. Эволюция популярных языков программирования
Мы ожидаем постоянных изменений от всех аспектов разработки: платформ программирования, языков, операционной среды, технологий обеспечения персистентности, облачных решений и проч. Мы знаем, что изменения технологий или предметной области неизбежны, пусть и не можем предсказать, когда конкретно они произойдут или какие из них сохранятся. Следовательно, мы должны проектировать системы с учетом будущих изменений.
Если экосистема меняется неожиданно и изменения невозможно предсказать, какова альтернатива фиксированным планам? Архитекторы систем предприятий и разработчики должны адаптироваться. Традиционно стратегия долгосрочного планирования существовала не в последнюю очередь потому, что ПО стоило дорого. Однако современные подходы к разработке опровергают эту предпосылку, поскольку благодаря автоматизации ручных процессов и другим достижениям, таким как DevOps, изменения стали менее дорогостоящими.
За многие годы лучшие разработчики осознали, что одни части систем труднее изменять, чем другие. Вот почему программная архитектура определяется как «то, что трудно поддается дальнейшим изменениям». Это удобное определение делит изменения на те, которые осуществить легко, и те, которые осуществить действительно сложно. К сожалению, это определение также породило предвзятое представление об архитектуре: разработчики изначально уверены в том, что вносить изменения сложно, и это становится самореализующимся пророчеством.
Несколько лет назад архитекторы-новаторы вновь обратились к проблеме «трудных изменений»: что, если встроить способность изменения в архитектуру? Другими словами, если сделать простоту изменений основополагающим принципом архитектуры, то изменения перестанут быть трудными. Встраивание изменяемости в архитектуру, в свою очередь, ведет к возникновению совершенно нового набора моделей поведения, что снова нарушает динамическое равновесие.
Даже если экосистема не меняется, что делать с постепенной эрозией характеристик архитектуры? Архитекторы создают модели архитектуры, которые затем подвергаются воздействию реальных условий реализации того, что лежит поверх этих моделей. Как архитекторам защитить выделенные ими важные компоненты?
Как, построив архитектуру, предотвратить постепенное ухудшение ее качества
Во многих организациях происходят негативные процессы, часто называемые «гниением». Архитекторы выбирают определенные архитектурные модели для обработки бизнес-требований и «-остей», но качество этих характеристик часто снижается со временем. Например, если архитектор создал многоуровневую архитектуру с верхним уровнем представления, нижним уровнем персистентных структур данных и несколькими промежуточными уровнями, то, чтобы повысить производительность, разработчики отчетов часто будут просить разрешения на прямой доступ к данным из уровня представления, минуя другие уровни. Архитекторы создают уровни, чтобы изолировать изменения. Затем разработчики обходят эти уровни, увеличивая связанность и делая выделение уровней бессмысленным.
Как архитекторам защитить выделенные ими характеристики архитектуры от разрушения? Добавление способностиэволюционировать (эволюционность) в качестве характеристики подразумевает защиту других характеристик в ходе эволюции системы. Например, если архитектор разработал архитектуру для масштабируемости, качество этой характеристики не должно ухудшаться по мере развития системы. Таким образом, способностьэволюционировать — это мета-характеристика, архитектурная обертка, которая защищает все остальные характеристики.
Механизм эволюционной архитектуры в значительной степени пересекается с проблемами и целями управления архитектурой — принципами, определяющими дизайн, качество, безопасность и другие вопросы. В этой книге описаны различные способы, позволяющие автоматизировать управление эволюционной архитектурой.
Почему архитектура эволюционная
Частый вопрос об эволюционной архитектуре касается самого ее определения: почему ее называют эволюционной архитектурой, а не как-то иначе? Другие возможные термины — инкрементная, непрерывная, адаптивная, реактивная, эмерджентная и другие. Но ни один из этих терминов не отражает всю полноту описываемого понятия. Определение эволюционной архитектуры, которое мы приводим здесь, включает две важнейшие характеристики: инкрементность и управляемость.
Термины непрерывная (continual), адаптивная (agile)и эмерджентная (emergent)отражают изменчивость во времени — несомненно, критически важную характеристику эволюционной архитектуры, но ни один из этих терминов не говорит о том, как изменяется архитектура или какой может быть желаемая конечная архитектура. Хотя все термины подразумевают изменяющуюся среду, ни один из них не описывает, как должна выглядеть архитектура. Слово управляемая в нашем определении указывает, какую архитектуру мы хотим получить, — нашу конечную цель.
Мы предпочитаем слово эволюционная, а не адаптируемая, потому что нас интересуют архитектуры, претерпевающие фундаментальные эволюционные изменения, а не те, которые были исправлены и адаптированы до возрастающей непонятной случайной сложности. Адаптация подразумевает поиск способа заставить что-то работать, неважно, насколько элегантно или долговечно найденное решение. Чтобы создавать архитектуры, которые действительно развиваются, архитекторы должны обеспечивать поддержку реальных и постоянных, а не временных изменений. Возвращаясь к метафоре из естествознания, эволюция — этопроцесс создания системы, которая соответствует своему назначению и способна выживать в постоянно меняющейся среде жизнедеятельности. Системы могут иметь отдельные адаптации, но архитекторы должны в первую очередь думать о способности к эволюции всей системы в целом.
Еще одно полезное для архитекторов сравнение — это сравнение эволюционной архитектуры и эмерджентного дизайна, и они должны осознавать, почему не существует понятия «эмерджентная архитектура». Одно из ошибочных представлений об agile-разработке — это то, что в ней якобы отсутствует архитектура: «Давайте просто начнем писать код, а архитектура подтянется по ходу дела». Однако это зависит от простоты проблемы. Рассмотрим строительство. Как мы уже говорили, если вы строите собачью будку, вам не нужна архитектура; вы можете пойти в хозяйственный магазин, купить доски и сколотить будку. Но если вы строите 50-этажное офисное здание, без архитектуры не обойтись! Точно так же, если вы создаете простую систему каталогов для небольшого количества пользователей, вы, скорее всего, обойдетесь без подробного планирования. Однако если вы проектируете высокопроизводительную систему для большого числа пользователей, вам необходим план! Agile-архитектура — это не отсутствие архитектуры; это отсутствие бесполезной архитектуры — излишней бюрократии, которая не добавляет ценности процессу разработки.
Еще один фактор, усложняющий архитектуру ПО, — различие в проектируемой сложности. Часто речь идет не о простой и сложной системах, а о системах, которые сложны по-разному. Другими словами, каждая система имеет уникальный набор критериев успеха. Хотя мы обсуждаем архитектурные стили, такие как микросервисы, каждый стиль по своей сути — это основа для сложной системы, которая растет и становится непохожей ни на какую другую.
Аналогично, если архитектор строит очень простую систему, он может не сильно заботиться об архитектуре. Однако сложные системы требуют целенаправленного проектирования и наличия отправной точки. Эмерджентность предполагает, что вы можете начать с нуля, в то время как архитектура предоставляет строительные леса, или структуру, для остальных частей системы — то, с чего можно начать.
Концепция эмерджентности также подразумевает, что команды могут медленно продвигаться к идеальному архитектурному решению. Однако, как и в строительстве зданий, идеальной архитектуры не существует, есть только способы, которыми архитекторы приходят к различным компромиссам. Для успешной реализации большинства проблем подходит множество разных архитектурных стилей. Однако какие-то стили будут лучше соответствовать проблеме, подразумевая меньшее сопротивление и меньшее количество обходных путей.
Одна из ключевых особенностей эволюционной архитектуры состоит в том, что необходимость обеспечивать определенную структуру и управление для поддержки долгосрочных целей соединяется в ней с отсутствием формальностей и трения.
Итоги
Полезные программные системы не статичны. Они должны расти и меняться по мере изменения предметной области и развития экосистемы, предоставляя новые возможности и усложняясь. Архитекторы и разработчики могут обеспечивать плавную эволюцию программных систем, но они должны понимать, какие методы разработки для этого лучше использовать и как структурировать свою архитектуру, чтобы способствовать изменениям.
Кроме того, на архитекторов возложена задача управлять продуктами, которые они разрабатывают, и методами разработки, которые они используют. К счастью, механизмы, которые мы описываем и которые облегчают эволюцию, также позволяют автоматизировать действия по управлению ПО. В следующей главе мы подробно рассмотрим, как это сделать.
1В литературе приняты два варианта перевода architecture characteristics — «характеристики архитектуры» или «свойства архитектуры». Мы остановились на первом варианте. —Примеч. ред.
2Речь идет о связанности между отдельными модулями и функциональной связанности (связности) элементов модуля. — Примеч. науч.ред.
