Обзор “Fundamentals of Software Architecture”

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

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

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

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

  1. Foundations

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

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

  • of execution — the order of execution of multiple components is important

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

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

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

  • Rule of Degree: convert strong forms of connascence into 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, …

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

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

  • Извлекать из информации о домене (domain concerns)

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

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

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

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

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

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

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

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

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

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

  • Actor/Actions approach — в основе подхода определение акторов, которые выполняют некоторые действия с системой

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

Architecture Styles

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

Fallacies of distributed computing

  1. The Network Is Reliable

Styles

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

  • Layered Architecture Style — стандартный архитектурный стиль, ориентированный на разделение по техническому стеку (front, back, database)
Рис.4 “Архитектурные стили”

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

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

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

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

Techniques and Soft Skills

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

  • Covering Your Assets Anti-Pattern

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

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

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

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

Выводы

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

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.