Обзор “Fundamentals of Software Architecture”

Бывают книги, которые можно читать запоем, а бывают те, что требуют вдумчивого чтения. Книга "Fundamentals of Software Architecture" от Neal Ford, Mark Richards относится ко второй категории. Я ее читал по вечерам на протяжении почти месяца:)

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

Рис. 1 “Обложка книги”

Книга состоит из трех частей:

1. Foundations
2. Architecture Styles
3. Techniques and Soft Skills

Foundations

Первая часть начинается с рассмотрения архитектурного мышления, которое опирается на широкий технический кругозор, анализ компромиссов (trade-offs), понимание business drivers. Дальше авторы переходят к обсуждению концепции модульности (modularity) и рассматривают довольно стандартные понятия cohesion и coupling, при помощи которых можно оценить насколько правильно выполнено разделение на модули. Довольно интересны размышления об абстрактности, нестабильности и distance from the main sequence. Дальше авторы подробно разбирают такую метрику как connascence, которая позволяет размышлять о сложности, вызванной отношениями зависимости в ООП. Connascence это объектно-ориентированная версия coupling, который изначально был введен для структурного проектирования.

Connascence

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

— of name — multiple components must agree on the name of an entity
— of type — multiple components must agree on the type of an entity
— of meaning or of convention — multiple components must agree on the meaning of particular values
— of position — multiple entities must agree on the order of values
— of algorithm — multiple components must agree on a particular algorithm

А к динамической connascence относятся:

— of execution — the order of execution of multiple components is important
— of timing — the timing of the execution of multiple components is important — of values — occurs when several values relate on one another and must change together
— of identity — occurs when several values relate on one another and must change together

Причем эти варианты перечислены в порядке нарастания плохого эффекта от их присутствия (в приложенной картинке указано направления для рефакторинга).

Рис. 2 “Направление рефакторинга“

В итоге, авторы проводят связь между coupling и connascence, а также дают рекомендации по улучшению программного обеспечения:

— Rule of Degree: convert strong forms of connascence into weaker forms of connascence
— Rule of Locality: as the distance between software elements increases, use weaker forms of connascence

Напоследок авторы вводят определение кванта архитектуры

Architecture quantum — An independently deployable artifact with high functional cohesion and synchronous connascence

Архитектурные характеристики

Дальше авторы переходят к архитектурные характеристикам (-ilities), которые раньше назывались нефункциональными требованиями, потом получили новое название атрибуты качества, которое потом переросло в архитектурные характеристики:) Авторы аргументируют эти изменения тем, что "архитектурные характеристики" звучит внушительнее:)

Рис.3 “Связь между архитектурными характеристиками и дизайном ПО”

В итоге, эти характеристики группируются по классам:

• Operational Architecture Characteristics — такие эксплуатационные характеристики, как availability, performance, reliability, scalability, …
• Structural Architecture Characteristics — такие структурные характеристики, относящиеся к качеству кода и его структуры, как configurability, extensibility, maintainability, portability, supportability, upgradability, …
• Cross-Cutting Architecture Characteristics — не попавшие в предыдущие категории, такие как: authentication, authorization, security, supportability, …

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

Но перед тем как переходить к самим типовым архитектурам надо сначала понять, а как же собственно определять -ilities во время работы над проектом. Их можно

• Извлекать из информации о домене (domain concerns)
• Извлекать из требований, причем там есть как явные (explicit) так и скрытые (implicit) архитектурные характеристики

Дальше надо придумывать как их можно измерять и как ими можно управлять, а здесь мы сразу возвращаемся к подходу fitness functions, который изначально был описан в предыдущей книге Нила Форда "Building Evolutionary Architectures".

После того, как мы определились с характеристиками, мы возвращаемся к более осязаемым вещам, а именно к компонентам, из которых собирается программное обеспечение. Авторы описывают компоненты так

Components offer a language-specific mechanism to group artifacts together, often nesting them to create stratification

Компонентами могут быть

• libraries — обертки над общим кодом, со своим API и исполняющиеся в том же адресном пространстве, доступные через вызовы функций
• layers — архитектурные уровни, часто представленные в слоеной архитектуре
• services — обертки над общим кодом, со своим API и исполняющиеся в другом адресном пространстве и доступные через сетевые вызовы

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

• tech partitioning — тут получается классическая слоеная архитектура
• domain partitioning — тут получается сервисная архитектура

Интересно, что тут появляется на сцене Закон Конвея, который объясняет доминирование слоенной архитектуры при наличии функциональных отделов (бекенд разработчиков, фронтенд разработчиков, DBA и т.д.)

organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations

Для правильного выделения компонентов авторы рекомендуют подходы:

• Actor/Actions approach — в основе подхода определение акторов, которые выполняют некоторые действия с системой
• Event Storming — в основе подхода предположение, что в системе используются сообщения или события для коммуникаций между различными компонентами. Рекомендую прочитать одноименную книгу Event Storming автора подхода Alberto Brandolini. Я писал на нее отзыв
• Workflow approach — моделирование потока работ, которое похоже на event storming, но без явного ограничения на построения message-based system

На этом заканчивается наше обсуждение основ и авторы переходят к рассмотрению стилей

Architecture Styles

Но перед рассмотрением самих стилей авторы рассматривают базис, в который входит сравнение монолитных и распределенных систем. И они перечисляют Fallacies of distributed computing, которые в 90-е годы изложил L Peter Deutsch из Sun Microsystems. Эти заблуждения настолько часты, что и нам не грех их тут воспроизвести

Fallacies of distributed computing

1. The Network Is Reliable
2. Latency Is Zero
3. Bandwidth Is Infinite
4. The Network Is Secure
5. The Topology Never Changes
6. There Is Only One Administrator
7. Transport Cost Is Zero
8. The Network Is Homogeneous

Styles

Ниже приведены рассматриваемые авторами архитектурные стили

• Layered Architecture Style — стандартный архитектурный стиль, ориентированный на разделение по техническому стеку (front, back, database)
• Pipeline Architecture Style —стиль pipes из Unix, отлично подходит для обработки данных
• Microkernel Architecture Style — стиль с ядром и расширением функционала через плагины
• Service-Based Architecture Style — отдельные крупные сервисы зачастую с общей базой данных
• Event-Driven Architecture Style — этот архитектурный стиль предполагает асинхронное общение и может быть использован как в одиночку, так и подмешан к другим архитектурным стилям
• Space-Based Architecture Style — этот стиль предназначен для решения вопросов с high scalability, elasticity, and high concurrency
• Orchestration-Driven Service-Oriented Architecture — уникальный архитектурный стиль, когда пользователи наслаждаются минусами распределенных и монолитных систем одновременно:)
• Microservices Architecture — популярный стиль, который неплохо раскрывает Sam Newman в книгах Monolith to Microservices и Building Microservices

Рис.4 “Архитектурные стили”

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

Рис. 5 “Сравнительные параметры архитектурных стилей”

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

Но это еще не все, что требуется в работе архитектора …

Techniques and Soft Skills

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

• Covering Your Assets Anti-Pattern
• Groundhog Day Anti-Pattern
• Email-Driven Architecture Anti-Pattern

После этого авторы обсуждают вопрос архитектурной значимости (architecture significant) и фиксации решений при помощи использования ADR (Architecture Decision Records) и RFC (Request For Comments).

Также архитекторам надо не забывать про анализ архитектурных рисков с упоминанием матрицы рисков (impact/likelihood) и проведения сессий risk storming для совместного определения и оценки рисков. И также надо уметь проводить презентации своих ошеломляющих архитектурных решений — главное, чтобы ошеломление было не от сложности подачи материала:)

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

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

Выводы

Книга является качественным обзором современных подходов к проектированию программного обеспечения. Определенно она стоит внимательного прочтения.