Обзор книги “Software Architecture for Busy Developers”
На новогодних каникулах я прочитал простую и понятную книгу “Software Architecture for Busy Developers”, изданную в конце 2021 года в издательстве Packt. Ее написал Stéphane Eyskens, который является Cloud and Cloud Native Architect и Azure MVP. Содержание книги показалась мне достойным краткого саммари… ну и мне показалась забавной обложка книги, чего уж там:)
Содержание книги разбито на 5 частей и 7 глав, которые представлены на рисунке ниже.
Все начинается с введения, а именно с первой главы
Introducing Software Architecture
В которой дается определение что такое software architecture. Вообще это стандартная фишка книг по архитектуре — начинать с определения. Классно, что в этой книге автор не заморачивается и выдает определение, схематически представленное на рисунке ниже.
Software Architecture in a nutshell
Кстати, несколько альтернативных определений можно прочитать в моей статье “Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения”.
Закончив с определением, автор переходит к более интересной части, а именно
A software Architecture Duties
Где он выделяет пять пунктов, приведенных ниже
Дальше автор решает перечислит разные виды архитектуры и рассказать про что они и делает это в части
Introducing the different architecture disciplines
На рисунке ниже приведены пять видов архитектуры и архитекторов. Для каждого вида архитекторов указано на чем он фокусируется и за что он отвечает по мере уменьшения важности.
Дальше автор выбирает из этих зон ответственности те, которые свойственны именно роли software architect и получается следующий список
На этом вводная глава заканчивается и автор переходит к рассказу про
Exploring Architecture Frameworks and Methodologies
В этом рассказе автор концентрируется на трех видах архитектуры: enterprise, security, infrastructure. Причем для каждого вида он указывает фреймворки и инструменты, которые являются стандартом де-факто.
Почти каждый желтый прямоугольник на картинке выше тянет на отдельную статью, а возможно и книгу. Поэтому мы не будем подробнее останавливаться на них в кратком саммари и перейдем сразу к вкусной части про
Understanding ATAM and the Software Quality Attributes
Это очень интересная глава посвящена методу анализа архитектурных компромиссов, в котором на входе у нас есть два вида пригодности системы:
Fit for purpose— система соответствует функциональным требованиям и соответствует назначениюFit for use— работает надежно и пригодна для использования
В попытке удовлетворить эти запросы обычно и требуется идти на архитектурные компромиссы, но … делать это стоит проведя тщательный анализ, который включает изучения влияния наших решений на quality attributes (атрибуты качества) системы.
ATAM (Architecture Tradeoff Analysis Method) содержит следующие основные моменты
Если говорить на пальцах, то
Sensitivity points—это решения которые влияют только на один атрибутTrade-off points— это архитектурные решения, которые влияют на несколько атрибутов и обычно при выборе мы жертвуем одним из них в пользу другогоRisksиNon-risks— это риски и возможности от архитектурных решений
В этом методе много говорится про влияние на атрибуты качества системы, но как понять а какие атрибуты качества важны для нас. Один из вариантов — это стартануть с того, чтобы понять какие SLA у нашей системы, например, очень важно понять какие показатели точки восстановления RPO (Recovery Point Objective) и времени восстановления RTO (Recovery Time Objective). Другие важные параметры — это желаемая скорость поставки фич на рынок (TTM) и ожидания по совокупной стоимости владения решением (TCO).
Если же говорить про атрибуты качества системы, то наиболее часто встречаются следующие.
Но важно, что в каждом конкретном случае список основных атрибутов качества системы является специфичным и зависит от контекста и ожиданий стейкхолдеров.
На самом деле ATAM (Architecture Tradeoff Analysis Method) позволяет работать в рамках трех сценариев, из которых вариант с use cases является основным. В нем описываются основные сценарии, а дальше ожидания от желаемой архитектуры.
Зачастую это описание ожиданий в рамках сценариев можно сделать в виде Utility Tree, как показано на примере ниже, где проектировалась система для загрузки и дальнейшей обработки данных (подробности рекомендую изучить в оригинальной книге).
На этом краткое введение в ATAM заканчивается и автор переходит к
Reviewing the Historical Architecture Styles
Автор решает рассмотреть 3 основных стиля: монолит, SOA и микросервисы. На самом деле архитектурных стилей гораздо больше, чем рассматривает автор, и об этом мы можете узнать в моей статье Обзор “Fundamentals of Software Architecture”.
Если же рассматривать эволюцию основных подходов вида Monolith > SOA > Microservices, то можно посмотреть ниже на сводную таблицу с преимуществами и вызовами каждой из указанных архитектур, которые привел автор в своей книге… а также можно почитать мою статью “Современные подходы к разработке программного обеспечения”
После экскурса в эволюцию подходов автор переходит в главу про
Design Patterns and Clean Architecture
Глава состоит из ревью паттернов, которые были приведены в книге GoF, а также рассмотрения подходов чистой архитектуры. Причем паттерны рассматриваются не все, а избранные и приведенные на рисунке ниже
На самом деле для более глубокого погружения в тему паттернов и чистой архитектуры я рекомендую почитать мою статью из курса про архитектуру “Essential Architecture #Code”. Там есть и про паттерны и про чистую архитектуру (как минимум про SOLID и компонентные принципы).
В конце главы автор приводит 10 запахов, на которые он обращает внимание при ревью кода или анализе выдачи статических анализаторов кодовой базы.
На этом глава заканчивается и автор переходит к
Impact of the Cloud on the Software Architecture Practice
В которой он рассматривает варианты облачных решений, которые приведены ниже. Отдельно стоит обратить внимание, что слева-направо увеличивается количество операционной работы и сокращается эффективность затрат.
Дальше автор приводит свою версию таблички с отображением основных атрибутов качества для разных видов cloud предложений.
Ну и напоследок автор разбирается с тем, что из себя представляет Cloud и Cloud Native подходы к разработке программного обеспечения. Версия автора доступна на рисунке снизу.
Ну и финальной главой книги является обзор
Trendy Architectures and Global Summary
Глава начинается с того, что сейчас стандартом являются API-driven архитектуры, у которых существуют такие паттерны.
Кстати, я тоже как-то написал статью на эту тему с названием “Как сделать API удобным для клиентов, особенно мобильных клиентов”
Ну а дальше глава продолжается примерами создания микросервисов при помощи dapr (Distributed Application Runtime), а также FaaS при помощи Azure function.
И заканчивается книга несколькими абзацами, из которых я вынес главное в цитату ниже.
As you understood from the initial chapter, there is no single vision of software architecture. I think that a good software architect must specialize in application development and architecture, as well as understand the bigger picture. A good software architect must be able to interact with every type of stakeholder
Надеюсь, что вам понравилось краткое саммари книги и вы решите изучить оригинал:)
