Пригодность и компромиссы

Рамка пригодности

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

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

Силы приходят с двух сторон: функциональные требования (что система должна делать) и атрибуты качества (насколько хорошо она должна это делать и при каких ограничениях). Функциональные требования — более лёгкая часть для рассуждений: их можно специфицировать, тестировать и отслеживать. Атрибуты качества — там, где живут структурные решения.

«Ilities»: конкурирующие атрибуты качества

Атрибуты качества часто называют «-ilities» (от английского суффикса), потому что многие их имена оканчиваются на это сочетание: maintainability, deployability, testability, scalability, reliability, security, observability. Каждый описывает измерение, по которому можно оценить систему. Проблема в том, что они тянут в противоположных направлениях.

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

Deployability — насколько быстро и безопасно изменение попадает в production? Микросервисы максимизируют её (каждый сервис деплоится независимо), но переносят связанность из кода в инфраструктуру: сервисные контракты, управление версиями и распределённые режимы отказов.

Testability — насколько легко можно верифицировать поведение в изоляции? Dependency injection и паттерны ports/adapters делают unit-тестирование тривиальным, но добавляют интерфейсные слои, которые могут скрывать, а не раскрывать замысел в простых случаях.

Scalability — может ли система обрабатывать растущую нагрузку? Stateless, секционированные сервисы масштабируются горизонтально, но требуют, чтобы домен был сформирован вокруг схемы разбиения, что конфликтует с едиными доменными моделями.

Observability — можно ли понять, что делает система, когда что-то идёт не так? Монолит с хорошим логированием часто более наблюдаем, чем распределённая система, где один запрос трассируется через двенадцать сервисов.

Каждое архитектурное решение одновременно двигает несколько «ilities». Вынос billing в отдельный сервис улучшает deployability и scalability компонента billing; ухудшает observability и увеличивает поверхность для распределённых сбоев. Выбор — не «что лучше», а «какой регулятор наиболее важен для сил этой системы прямо сейчас».

Бегущий пример: B2B-платформа заказов и биллинга

На протяжении всего трека повторяется одна система-пример: B2B-платформа заказов и биллинга для SaaS-компании. Заказы поступают через клиентский API. Они проходят ценообразование, расчёт налогов и рабочие процессы согласования. Они поступают в биллинг, который генерирует инвойсы, применяет скидки и инициирует сбор платежей. Отчёты биллинга питают финансовые дашборды. Разрешение споров требует просмотра полной истории заказа.

Это реальный домен с реальными силами:

• Несколько точек входа: заказы поступают через API, webhook и внутренние admin-инструменты.
• Разные темпы изменений: правила ценообразования меняются ежемесячно; логика сбора платежей меняется редко.
• Требования соответствия: записи биллинга — это неизменяемые аудит-трейлы; GDPR применяется к данным клиентов.
• Давление интеграции: платформа интегрируется с тремя платёжными процессорами, двумя ERP-системами и порталом клиента.
• Структура команды: продуктовая команда владеет потоком заказов; команда finance-tech владеет биллингом.

Эта платформа — не игрушка. Она вернётся, когда будем рассматривать layered architecture (единица 03), hexagonal architecture (единица 04), DDD bounded contexts (единица 06), CQRS (единица 07), event sourcing (единица 08) и декомпозицию (единица 10). Домен остаётся прежним; структура меняется каждый раз, когда мы применяем другой набор сил.

Честное чтение компромисса

Стандартный инженерный провал при рассуждении об архитектуре — асимметричный компромисс: перечислить все преимущества выбранного подхода и ни одного из его издержек, затем перечислить все издержки отвергнутого подхода и ни одного из его преимуществ. Именно так команды приходят к микросервисам для решения проблемы скорости деплоя, а потом два года борются с распределёнными транзакциями и query fan-out.

Честно прочитанный компромисс имеет такую форму:

• Каким силам отвечает эта структура? (Назови их конкретно, не расплывчато.)
• Чего это стоит? (Назови «ilities», которые ухудшаются, и операционные накладные расходы, которые добавляются.)
• Каким силам эта структура не отвечает? (Будь явным в том, что ты принимаешь.)
• Что должно измениться, чтобы другая структура стала правильной? (Это эволюционный выход — если система столкнётся с силой, которую текущая структура не может обработать, что является триггером?)

Эта рамка появляется на протяжении всего трека. Это не чеклист для механического следования — это привычка явно называть силы перед оценкой структуры.