Перейти к содержанию

Границы архитектурного и инфраструктурного слоёв

Требования применяются к нормативным зависимостям и изменениям на границе архитектурного и инфраструктурного слоёв. Уровни обязательности определены в корневом README.md.

Запись architecture:<ID> означает требование с указанным стабильным ID из архитектурного слоя той же зафиксированной версии объединённого стандарта. Ограниченный диапазон architecture:<PREFIX>-001–<PREFIX>-009 означает все существующие active ID этого префикса между опубликованными границами; пропущенный или retired номер не считается ссылкой.

INF-ARC-001. Разрешение архитектурной ссылки

Уровень: MUST

Применяется к: каждой ссылке вида architecture:<ID> или ограниченному диапазону

Нормативная ссылка должна указывать точный ID либо ограниченный диапазон. Wildcard-ссылка на весь префикс запрещена: новый ID не должен становиться зависимостью инфраструктурного стандарта без отдельного review. Ссылка задаёт исходный контракт, а не копирует его формулировку.

Ссылка должна разрешаться по глобальному каталогу требований в том же Git commit, который указан в standards.commit_sha manifest прикладного проекта. Точный ID и обе границы диапазона должны существовать, принадлежать архитектурному слою и не быть retired. Если условие не выполнено либо зафиксированная версия меняет семантику требуемого контракта, затронутое изменение должно быть остановлено.

Обоснование

Одинаковый ID в неизвестной версии не определяет применимый контракт.

Проверка

  • поиск ID в зафиксированном checkout объединённого стандарта;
  • сверка слоя, tag и commit;
  • негативный тест отсутствующего и retired ID.
  • статическая проверка отсутствия wildcard-ссылок.

Исключения

Не допускаются.

INF-ARC-002. Границы между приложением и инфраструктурой

Уровень: MUST

Применяется к: проектированию deployment-конфигурации

Инфраструктура должна реализовать применимые архитектурные контракты, не переопределяя их семантику:

  • build и release: architecture:DEP-CI-001–DEP-CI-005, architecture:DEP-IMG-001–DEP-IMG-013 и architecture:DEP-SUP-001–DEP-SUP-005;
  • rollout: architecture:DEP-ROL-001–DEP-ROL-005;
  • конфигурация и секреты: architecture:BE-CONF-001–BE-CONF-013 и architecture:SEC-SCRT-006–SEC-SCRT-009;
  • health и shutdown: architecture:BE-HLTH-001–BE-HLTH-009 и architecture:BE-SHUT-001–BE-SHUT-007;
  • ресурсы и миграции: architecture:BE-RSRC-001–BE-RSRC-003 и architecture:BE-MIG-001–BE-MIG-004;
  • телеметрия: применимые architecture:OBS-LOG-001–OBS-LOG-008, architecture:OBS-MET-001–OBS-MET-010, architecture:OBS-TRACE-001–OBS-TRACE-009 и architecture:OBS-ERR-001–OBS-ERR-009;
  • backup и защита данных: применимые architecture:DATA-BACK-001–DATA-BACK-005 и architecture:DATA-CLS-001–DATA-CLS-003;
  • TLS и публичная identity: применимые architecture:SEC-TLS-001–SEC-TLS-005, architecture:SEC-AUTHN-001–SEC-AUTHN-012 и architecture:SEC-AUTHZ-001–SEC-AUTHZ-012;
  • публичный HTTP traffic control: применимые architecture:BE-HTTP-001 и architecture:BE-HTTP-011;
  • capacity, SLO и incident response: применимые architecture:OPS-CAP-001–OPS-CAP-003, architecture:OPS-SLO-001–OPS-SLO-005 и architecture:OPS-INC-001–OPS-INC-004;
  • события и NATS: применимые architecture:INT-EVT-001–INT-EVT-014 и architecture:INT-NATS-001–INT-NATS-008.

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

Отдельный технологический архитектурный документ требуется только тогда, когда платформенный сервис добавляет наблюдаемую гарантию приложения сверх общих контрактов конфигурации, TLS, состояния, backup или SLO. PostgreSQL, Valkey и object storage MAY реализовывать эти общие контракты без отдельного технологического архитектурного ID. Интеграция, для которой платформа не предоставляет deployment- или runtime-механизм, не требует симметричного инфраструктурного документа.

Обоснование

Разделение исключает две конкурирующие нормы для одного поведения приложения.

Проверка

  • review mapping архитектурных ID к manifests и release gates;
  • проверка каждого технологического profile: общий либо технологический архитектурный контракт и фактически предоставляемый платформенный механизм;
  • проверка отсутствия локального переопределения семантики.

Исключения

ADR MAY временно закрыть пробел до обновления стандарта, если имеет владельца и срок пересмотра.

INF-ARC-003. Владение нормой и порядок изменения

Уровень: MUST

Применяется к: требованию или изменению на границе приложения и инфраструктуры

Наблюдаемое поведение приложения, контракт данных или интеграции, release-инвариант и пользовательский SLI/SLO должны иметь единственный нормативный источник в архитектурном стандарте. Инфраструктурное требование должно регулировать только способ реализации или проверки этого контракта в deployment, runtime либо платформе и ссылаться на исходный архитектурный ID.

Если изменение требует обеих норм, архитектурный контракт и зависящая от него инфраструктурная реализация должны изменяться одним merge request. Обратная нормативная ссылка из архитектурного слоя на инфраструктурный ID запрещена.

Обоснование

Один владелец семантики и направленная зависимость исключают конкурирующие формулировки и цикл версий между стандартами.

Проверка

  • review каждого межпроектного изменения по границе ответственности;
  • проверка ссылки на архитектурный ID того же commit;
  • поиск скопированных норм и обратных инфраструктурных ссылок.

Исключения

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