Архитектурные стандарты
Как применять обязательные правила MTB ESB при проектировании интеграций.
Architecture & Standards
Этот раздел содержит практические архитектурные правила для API, сообщений, маршрутов и данных. Обзор компонентов находится в Introduction; здесь описано, как проектировать совместимые интеграции.
Иерархия требований
- Требования безопасности и регуляторные ограничения.
- Утверждённые platform policies.
- API и event contracts.
- Architecture Decision Records для исключений.
- Локальные implementation details.
Исключение должно быть явным
Если интеграция не может выполнить стандарт, команда оформляет причину, риск, owner, компенсирующие меры и срок пересмотра. Устная договорённость не является архитектурным решением.
Базовые принципы
- API-first и contract-first;
- слабая связанность Consumer и target system;
- business logic вне API Gateway;
- отдельные адаптеры для изоляции legacy;
- traceability и idempotency by design;
- отказоустойчивость с явными timeout/retry/DLQ;
- минимизация и ограниченное хранение данных;
- environment isolation и delivery через pipeline.
Навигация
API Design
Ресурсы, версии, данные и ошибки.
Messaging & Routing
Topics, keys, envelopes и маршруты.
Identity & Tracing
Consumer ID, request ID, traceparent и idempotency.
Reliability & Errors
Timeout, retry, DLQ, callback и recovery.
Architecture review output
Для новой интеграции review фиксирует:
- выбранный flow;
- API и message contracts;
- component ownership;
- data classification;
- security boundaries;
- reliability model;
- observability signals;
- открытые вопросы и ADR.