Архитектура и интеграция сервисов

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

Что это даёт в реальной работе

Показывает, почему хороший процесс может не работать из-за системных ограничений.
Связывает клиентский статус с real system of record.
Помогает обсуждать integration failures, retry, idempotency, reconciliation и fallback.
Делает нефункциональные требования частью сервисной модели.
Помогает понять, что должна видеть поддержка при обращении клиента.

Ключевые источники и идеи

Источник	Что взять для сервисной модели	Ограничение
Martin Fowler / EAA	application patterns, domain logic, transaction script, service layer, gateways	открытый каталог не заменяет книгу целиком
TOGAF / Desfray / Raymond	enterprise architecture, capability view, governance, roadmap, viewpoints, связь UML/BPMN	сохранена source card SJM Source - Desfray TOGAF UML BPMN 2014; официальный стандарт учитывать по лицензии
DoDAF	viewpoints, data-centric architecture description, traceability	оборонный контекст, переносить аккуратно
SOMF	service-oriented modeling	официальный надёжный источник не подтверждён: `source_required`
ISO/IEC/IEEE 42010	architecture description, stakeholders, viewpoints, model kinds	полный стандарт платный; открытый abstract достаточен только для рамки
Bass, Clements, Kazman	quality attributes, lifecycle, architecture evaluation	для глубокого конспекта нужен полный текст
Richards / Ford	architectural characteristics, trade-offs, fitness functions, ADR, architecture risk	сохранена source card SJM Source - Richards Ford Software Architecture 2025

Справочный слой

Справочный слой помогает привязать архитектуру к сопровождению сервиса. Для сервисной модели архитектура нужна не как отдельная “техническая папка”, а как слой проверяемых ограничений: что должно быть быстрым, доступным, наблюдаемым, безопасным, сопровождаемым и восстанавливаемым.

Что взять в работу

Architecture characteristics — качества сервиса должны быть явно названы: availability, latency, security, privacy, scalability, maintainability, observability, testability, deployability, resiliency.
Trade-off analysis — архитектурное решение почти всегда усиливает одни качества и ослабляет другие; это нужно фиксировать до запуска, а не после инцидента.
Fitness function — качество нужно переводить в проверяемый контроль: метрика, тест, alert, отчёт, checklist или автоматизированная проверка.
Architecture decision record — спорные решения по интеграциям, source of truth, retry, fallback, хранению статусов и доступам лучше фиксировать короткими ADR.
Coupling and cohesion и Modularity — границы сервиса должны уменьшать каскадные изменения и помогать сопровождению.
Enterprise architecture, TOGAF, Viewpoint — разные stakeholders видят один сервис через разные представления: клиент, поддержка, операции, IT, риски, compliance.
UML и BPMN — использовать как способ уточнить interaction/state/process view, а не как замену SJM.

Архитектурные fitness checks для сервиса

Качество	Как проверить в сервисной модели
Availability	есть monitoring/alert на критичный канал и зависимость
Latency	задан target для ожидания клиента и внутренней обработки
Observability	есть correlation ID, события, логи и владелец диагностики
Recoverability	описаны fallback, retry, компенсация и customer communication
Security / privacy	первая линия видит только безопасный минимум данных
Maintainability	изменение статуса, SLA или маршрута не требует ручных обходов
Testability	у критичных интеграций есть oracle, тестовые данные и synthetic check
Supportability	CRM/workflow/KB дают достаточно информации для ответа клиенту

Практический вывод

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

Как применять в сервисной модели

На SJM-карте фиксировать не только “система”, но и роль системы: channel, CRM, workflow, system of record, notification service, monitoring.
Для каждого критичного статуса указать источник истины.
Для каждой интеграции проверить: synchronous/asynchronous, timeout, retry, duplicate protection, fallback, reconciliation.
Для каждого customer-facing шага проверить качества: availability, latency, security, privacy, accessibility, observability, maintainability.
Для support-сценария указать, какие данные видит первая линия и где нужны ограничения доступа.

Связь с SJM

SJM без архитектурного слоя часто показывает симптомы, но не причины. Например:

клиент видит “операция в обработке”, но источник истины находится в другом контуре;
поддержка не может ответить, потому что CRM не получает событие из процессинга;
retry создаёт риск дубля;
SLA нарушается не из-за команды, а из-за внешней зависимости;
incident-review не может найти root cause без correlation ID и логов.

Связь с инструментами поддержки и сопровождения

Архитектурная заметка по сервису должна отвечать:

где лежит master-data;
какие системы участвуют в маршрутизации;
какие события передаются в мониторинг;
какие статусы попадают в CRM и систему обращений;
какие данные доступны первой линии;
где находится correlation ID;
как выглядит fallback при деградации;
кто владеет интеграцией.

Практический чек-лист

Есть список систем и их ролей.
Определён system of record для ключевых данных.
Описаны интеграции и внешние зависимости.
Указаны архитектурно значимые качества.
Есть observability: логи, метрики, trace/correlation ID.
Описан fallback и recovery.
Поддержка понимает, где смотреть статус и причину ошибки.
Есть owner для архитектурных решений.

Ограничения

Не превращать SJM в полную архитектурную документацию.
Не фиксировать реальные внутренние названия систем, если это не нужно или приватно.
Для SOMF, ISO/IEC/IEEE 42010 full text и Bass/Clements/Kazman полный материал пока не предоставлен: source_required.