Обзор книги “Software Architecture: The Hard Parts” — Part 6

Это финальная статья из серии обзоров книги “Software Architecture”, в которой мы заканчиваем обсуждение книги и рассматриваем последние главы “Contracts”, “Managing Analytical Data” и “Build Your Own Trade-Off Analysis”. Перед чтением этой статьи я рекомендую прочесть части 1, 2, 3, 4 и 5.

Contracts

Глава начинается с того, что авторы говорят, что контракты в архитектуре очень важны. Стандартное определение контракта выглядит так

contract
A written or spoken agreement, especially one concerning employment, sales, or tenancy, that is intended to be enforceable by law.

А определение от авторов расширяется до того, в котором мы говорим про любые зависимости.

hard parts contract
The format used by parts of an architecture to convey information or dependencies.

Авторы выделяют контракты разной строгости, приведенные ниже. Все начинается со строгих контрактов, условно remote procedure call с зафиксированной сигнатурой и заканчиваются условно пробросом произвольного набора ключей и значений в виде map.

Рис.1 “Contracts: Strict, Loose and Tunable”

Где-то посередине авторы размещают consumer-driven contracts, которые я отнес к настраиваемому уровню строгости, который определяют сами потребители. Дальше авторы внезапно вспоминают про stamp coupling и рассматривают его плюсы и минусы.

Рис.2 “Stamp Coupling for Workflow Management”

Managing Analytical Data

В этой главе авторы последовательно рассматривают модели data warehouse, data lake и data mesh. Для каждого из подходов авторы приводят набор плюсов и минусов.

Рис.3 “Managing Analytical Data”

Но разбор Влада Хононова в его книге “Learning Domain Driven Design” мне понравился больше. Прочитать обзор этой части его книги можно в моей обзорной статье “Learning Domain-Driven Design” — part IV (Data Mesh).

Из нового и интересного авторы этой книги вводят понятие data product quantum

DPQ represents a component owned by the domain team responsible for implementing the service. It overlaps information stored in the database, and may have interactions with some of the domain behavior asynchronously. The data product quantum also likely has behavior as well as data for the purposes of analytics and business intelligence.

Авторы выделяют три вида DPQ , приведенных на рисунке снизу.

Рис.4 “Data Product Quantum”

Build Your Own Trade-Off Analysis

Эта глава от авторов мне совсем не зашла, поэтому я решил рассказать про Architecture Tradeoff Analysis Method(ATAM), опираясь на описание из книги “Software Architecture for Busy Developers”, на которую я делал обзор. Собственно ATAM рассматривался в главе “Understanding ATAM and the Software Quality Attributes”. Это очень интересная глава была посвящена методу анализа архитектурных компромиссов, в котором на входе у нас есть два вида пригодности системы:

• Fit for purpose — система соответствует функциональным требованиям и соответствует назначению
• Fit for use — работает надежно и пригодна для использования

В попытке удовлетворить эти запросы обычно и требуется идти на архитектурные компромиссы, но … делать это стоит проведя тщательный анализ, который включает изучения влияния наших решений на quality attributes (атрибуты качества) системы.

Рис.5 “ATAM — Architecture Tradeoff Analysis Method”

ATAM (Architecture Tradeoff Analysis Method) содержит следующие основные моменты

Рис.6 “The most important concerns of ATAM”

Если говорить на пальцах, то

• Sensitivity points —это решения которые влияют только на один атрибут
• Trade-off points — это архитектурные решения, которые влияют на несколько атрибутов и обычно при выборе мы жертвуем одним из них в пользу другого
• Risks и Non-risks — это риски и возможности от архитектурных решений

В этом методе много говорится про влияние на атрибуты качества системы, но как понять а какие атрибуты качества важны для нас. Один из вариантов — это стартануть с того, чтобы понять какие SLA у нашей системы, например, очень важно понять какие RTO и RPO. Другие важные параметры — это желаемая скорость поставки фич на рынок (TTM) и ожидания по совокупной стоимости владения решением (TCO).

Рис.7 “Exploring quality attributes”

Если же говорить про атрибуты качества системы, то наиболее часто встречаются следующие.

Рис.8 “Commonly seen quality attributes”

Но важно, что в каждом конкретном случае список основных атрибутов качества системы является специфичным и зависит от контекста и ожиданий стейкхолдеров.

На самом деле ATAM (Architecture Tradeoff Analysis Method) позволяет работать в рамках трех сценариев, из которых вариант с use cases является основным. В нем описываются основные сценарии, а дальше ожидания от желаемой архитектуры.

Рис.9 “Scenarios of ATAM”

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

Рис.10 “Utility trees”

Итого

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

P.S.

Запись обсуждения этой части книги в нашем книжном клубе Code of Architecture представлена ниже.