Анализ трейдоффов

Словарь ATAM: sensitivity points, tradeoff points, риски

Architecture Tradeoff Analysis Method (ATAM) разработан в Software Engineering Institute (SEI) Университета Карнеги-Меллон. Полный процесс ATAM тяжеловесен — несколько дней структурированных воркшопов. Но вводимый им словарь легковесен и немедленно полезен для повседневных архитектурных рассуждений.

Три концепции важны:

Sensitivity point (точка чувствительности): проектное решение, оказывающее сильный эффект на одну quality attribute. Его изменение значительно улучшает или ухудшает эту характеристику, тогда как другие атрибуты относительно не затрагиваются. Пример: партиционирование таблицы событий заказов по customer ID значительно улучшает задержку запросов на отчёты по клиентам, с минимальным эффектом на пропускную способность записи или согласованность данных. Решение чувствительно к задержке.

Tradeoff point (точка трейдоффа): проектное решение, влияющее на несколько quality attributes в противоположных направлениях. Улучшение одной атрибуты ухудшает другую. Пример: event sourcing улучшает аудируемость и возможности темпоральных запросов — но ухудшает модифицируемость (неизменяемый журнал усложняет удаление по GDPR) и операционную простоту (перестройка проекций, управление снэпшотами). Решение — это tradeoff между аудируемостью и модифицируемостью.

Риск: архитектурное решение, которое может привести к тому, что quality attribute не достигнет требуемого уровня в каком-то будущем, правдоподобном, но ещё не реализованном сценарии. Пример: использование журнала событий как источника истины для PII клиентов — это риск, если к системе применяется регулирование права на удаление.

Словарь делает рассуждения точными: вместо «эта архитектура хороша» или «эта архитектура рискована» можно сказать «это решение — tradeoff point между аудируемостью и модифицируемостью — мы принимаем ухудшенную модифицируемость в обмен на аудируемость и должны явно миtigировать риск GDPR».

Применение ATAM-lite к биллинговой платформе

Команда биллинговой платформы, применяя словарь ATAM ретроспективно к решению об event sourcing, получила бы:

Quality attributes в области: аудируемость, задержка, модифицируемость, операционная простота, соответствие регулированию.

Решение: хранить агрегат заказов как журнал событий; состояние заказа восстанавливается воспроизведением событий.

Sensitivity point: производительность воспроизведения чувствительна к объёму журнала событий. По мере роста журнала время холодного старта воспроизведения растёт пропорционально.

Tradeoff point: неизменяемость журнала событий обменивает модифицируемость на аудируемость. Каждое событие сохраняется постоянно — это актив для аудиторских следов и обязательство для требований удаления данных. То же свойство, которое делает систему отличным аудитовым журналом, делает её плохо подходящей для систем, подпадающих под регулирование права на удаление.

Риск: если к этой системе применяется регулирование права на удаление, неизменяемый журнал событий сделает соответствие структурно сложным. Риск правдоподобен (GDPR вступил в силу в 2018 году; платформа работает в ЕС) и не смягчён на момент принятия решения.

Документирование этого на момент принятия решения — в ADR для event sourcing — не предотвратило бы проблему GDPR. Но сделало бы трейдофф явным, вынудило бы команду рассмотреть варианты смягчения на этапе проектирования, когда они дешёвы, и дало бы инженеру и юристу общий фрейм для разговора два года спустя.

Трек как инструментарий трейдоффов

Каждый раздел этого трека вводил структурный паттерн. Каждый паттерн — ответ на трейдофф. Оглядываясь назад:

Раздел 01 — Coupling и cohesion: фундаментальные силы. Каждое структурное решение обменивает зацепление (насколько модули знают друг о друге) на связность (насколько сфокусирован каждый модуль). Высокое зацепление обеспечивает разделяемое состояние и низкую задержку ценой независимой эволюции.

Раздел 02 — Направление зависимостей: стабильные абстракции (интерфейсы, порты) улучшают модифицируемость, позволяя конкретным реализациям меняться, не затрагивая вызывающих — ценой косвенности и абстракционных накладных расходов. DIP — это tradeoff point между модифицируемостью и простотой.

Раздел 03 — Слоевая архитектура: N-tier слоение улучшает разделение ответственностей и тестируемость — но строгая граница слоёв создаёт ловушку transaction-script и fat service layer. Анемичные доменные модели обменивают богатство на простоту.

Раздел 04 — Hexagonal: ports and adapters улучшают тестируемость (домен тестируем без инфраструктуры) и модифицируемость (инфраструктура заменяема) ценой структурных накладных расходов.

Раздел 05 — Clean/Onion: концентрическое правило зависимостей максимизирует изоляцию домена — ценой шаблонного кода use cases и «налога чистой архитектуры».

Раздел 06 — DDD: bounded contexts применяют языковые и модельные границы — улучшая точность модели и автономию команды ценой интеграционных накладных расходов (context maps, ACL, слои трансляции).

Раздел 07 — CQRS: разделение моделей чтения и записи улучшает масштабируемость чтения и ясность записи ценой сложности синхронизации. Модель чтения может быть устаревшей.

Раздел 08 — Event sourcing: неизменяемый журнал событий улучшает аудируемость и обеспечивает темпоральные запросы — ценой модифицируемости (GDPR), операционной сложности (проекции, снэпшоты) и eventual consistency. Как узнала биллинговая платформа.

Раздел 09 — Event-driven: хореография улучшает развязку и устойчивость ценой распределённой трейсируемости и согласованности. Оркестрация улучшает наблюдаемость и согласованность ценой зацепления центрального координатора. Саги обменивают согласованность на доступность.

Раздел 10 — Decomposition: modular monolith обменивает независимость деплоя на операционную простоту. Микросервисы обменивают операционную простоту на независимость деплоя и автономию команды. Distributed monolith — режим отказа при неправильном сочетании обоих.

Раздел 11 — Evolution: ADR’ы делают ПОЧЕМУ явным; fitness functions применяют, что структурные свойства выполняются. Оба — инвестиции в долгосрочную модифицируемость ценой краткосрочных накладных расходов.

Ни один из этих паттернов не является универсально правильным. Каждый — ответ на конкретный набор сил. Силы — это ограничение: размер команды, сложность домена, регуляторная среда, требования к производительности, организационная структура, скорость изменений. Паттерн — это ответ.

Мета-принцип: fitness for forces, а не универсальные best practices

Раздел 00 ввёл фрейм: нет лучшей архитектуры, есть только fit-for-forces. Это закрывающий тезис трека.

Каждый паттерн в этом треке имеет контекст, в котором он — правильный ответ, и контекст, в котором он — неправильный. Силы, делающие hexagonal architecture правильной для domain-heavy приложения (тестируемость, независимость от инфраструктуры, долгосрочная модифицируемость), отсутствуют в простом CRUD-сервисе. Силы, делающие event sourcing правильным для аудит-критичной финансовой системы (неизменяемая история, темпоральные запросы, соответствие регулированию), — это в точности силы, делающие его неправильным для потребительского приложения, подпадающего под право на удаление, где модифицируемость персональных данных — жёсткое требование.

Задача архитектора — не применить наиболее сложный доступный паттерн. Это — определить силы и выбрать структурный ответ, соответствующий этим силам с наименьшим количеством лишних трейдоффов.

ADR’ы и fitness functions — инструменты, делающие этот процесс долговечным:

• ADR фиксирует, какие силы присутствовали, какие трейдоффы были приняты и почему — чтобы будущие инженеры могли оценить, применимы ли силы по-прежнему.
• Fitness function применяет, что структурные свойства, взятые на себя командой, по-прежнему поддерживаются — чтобы архитектура не дрейфовала от намерения.

Архитектура — это глагол. Это непрерывный процесс оценки сил, выбора структурных ответов, фиксации обоснования и поддержания важных свойств. Вот что означает «архитектура — это глагол».