Обзор “Fundamentals of Software Architecture”

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

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

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

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

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 “Связь между архитектурными характеристиками и дизайном ПО”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Techniques and Soft Skills

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

После этого авторы обсуждают вопрос архитектурной значимости (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.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alexander Polomodov

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