Перейти к основному содержимому

Граф пересечений архитектурных осей — карта связей между всеми верхнеуровневыми контурами

Версия: 1.0 Дата: 25.04.2026 Статус: Готов к обсуждению

Назначение документа​

Этот документ — карта пересечений между всеми шестью архитектурными осями платформы Vitiana верхнего уровня. Он отвечает на вопрос: как именно оси связаны друг с другом, какие сущности и контуры пересекаются, какие правила применяются при кросс-осевых решениях.

Этот документ — практический инструмент для архитектора и команды. Когда меняется решение в одной оси, необходимо проверить, какие пересечения с другими осями требуют согласованного изменения.

Документ читается после изучения шести осевых документов:

Шесть осей — краткая карта​

ОсьНазваниеГлавный фокусДокумент
1Каноничная доменная осьСущности, контуры истины, жизненные циклыcanonical-domain-spine.md
2Поверхности взаимодействияSurfaces, контракты, видимостьlayers.md
3Платформа как продуктTariff tiers, dynamic pricing, DX, SLAplatform-as-product.md
4Ось данных и интеллектаСобытия, DWH, ETL, ML, A/Bdata-and-intelligence-spine.md
5Операционная осьМасштабирование, надёжность, инцидентыoperational-spine.md
6Связь с реализациейhome-to-go-api, технический долг, конвергенцияrelation-to-implementation-baseline.md

Почему пересечения важны​

Платформа Vitiana — не набор изолированных компонентов, а связная система. Изменение в одной оси неизбежно влияет на другие:

  • Изменение каноничной сущности (ось 1) влияет на видимость на поверхностях (ось 2), на структуру событий (ось 4), на операционные требования (ось 5).
  • Запуск нового tarif tier (ось 3) требует изменений в metering (ось 4), SLA (ось 5), capability scope сущностей (ось 1).
  • Переход в новую фазу packaging (ось 5) опирается на operational maturity (ось 4: monitoring), на коммерческие гарантии (ось 3: SLA), на каноничную модель (ось 1: stable model для миграции).

Без явной карты пересечений архитектор работает «в одной оси, забывая про соседние», что нарушает правило удержания контекста связанных логик и документов.

Матрица пересечений: 6×6​

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

Ось 1 (Каноничная доменная) → другие оси​

Ось 1 → Ось 2 (Поверхности)​

Связь: каноничные сущности проявляются на каждой поверхности с разной видимостью.

Главные правила:

  • одна каноничная сущность существует в одном экземпляре;
  • видимость per surface определяется политиками визибилити;
  • поверхности не дублируют сущности, они показывают разные view одних и тех же сущностей.

Матрица видимости — в overview/layers.md, часть «Связь с осью 1».

Ось 1 → Ось 3 (Платформа как продукт)​

Связь: некоторые каноничные сущности — главные продуктовые сущности.

Главные сущности:

  • Tenant — первичная сущность бизнес-модели;
  • Partner — отдельная категория Tenant с платным API-доступом;
  • Agency — отдельная категория Tenant с подпиской и комиссией;
  • ApiClient + ApiCredential — операционная единица доступа партнёра;
  • TourDraft + TourProposal — сущности отдельного paid Tour Builder tier;
  • UsageEvent + BillingEntry — сущности динамической тарификации.

Главные правила:

  • продуктовые сущности — это подмножество каноничных, не отдельная категория;
  • структура tier (Free / Starter / Professional / Enterprise) — реализуется как policy_set сущность, привязанная к Tenant.

Ось 1 → Ось 4 (Данные и интеллект)​

Связь: все каноничные сущности генерируют domain events; некоторые сущности являются производными от данных.

Главные правила:

  • domain events — это трансляция изменений каноничных сущностей, не отдельная категория данных;
  • analytical events — параллельный класс, наблюдает поведение вокруг каноничных сущностей;
  • FieldLineage (часть governance группы) — основа для data quality monitoring;
  • ML использует features, derived from caнonical entities + events;
  • replay events возможен потому, что каноничные сущности имеют стабильную идентичность.

Ось 1 → Ось 5 (Операционная)​

Связь: жизненный цикл сущностей определяет операционные требования.

Главные правила:

  • Booking — самый критический операционный домен (audit-grade durability, recovery procedures, SLA per tier);
  • Governance — операционный процесс с человеком в цикле;
  • Replay capability — для всех групп сущностей с persistent layer;
  • unknown_external_state в Booking lifecycle — first-class операционная категория, требует runbook;
  • transactional layer — самая высокая SLA (99.9%+ для Enterprise tier).

Ось 1 → Ось 6 (Реализация)​

Связь: каноничные сущности — целевая модель; текущие таблицы home-to-go-api — первая итерация.

Главные расхождения:

  • hotels schema смешивает Property и SupplierProperty — требует разделения;
  • Offer/Quote/Booking — не существуют как persistent сущности;
  • Governance layer — не реализован.

Полная карта — в overview/relation-to-implementation-baseline.md.

Ось 2 (Поверхности) → другие оси​

Ось 2 → Ось 1​

Обратная связь: поверхности диктуют правила видимости каноничных сущностей.

Главные правила:

  • для каждого поля каноничной сущности — явная политика visibility per surface;
  • visibility model — часть контракта поверхности, не runtime-фильтр.

Ось 2 → Ось 3 (Платформа как продукт)​

Связь: поверхности — это продуктовые поверхности.

Главные пересечения:

  • Partner API Surface = главный продукт B2B API marketplace;
  • Tour Builder Closed Surface = премиальный продукт со своим тарифом;
  • Agency Working Surface = собственный продукт для агентств;
  • B2C Storefront Surface = собственный канал продаж + demonstration.

Ось 2 → Ось 4 (Данные и интеллект)​

Связь: каждая поверхность — источник tracking events.

Главные правила:

  • B2C Storefront — самый интенсивный источник conversion analytics;
  • Partner API — usage metering для динамической тарификации;
  • Agency — agent workflow analytics;
  • Internal — операционная аналитика;
  • Tour Builder — composition analytics для ML compatibility scoring;
  • S2S — operational events.

Ось 2 → Ось 5 (Операционная)​

Связь: каждая поверхность определяет свои операционные требования.

Главные правила:

  • у каждой поверхности своё SLA (uptime, latency, freshness);
  • Partner API — самые жёсткие требования по contract stability;
  • B2C — самые жёсткие требования по latency для conversion;
  • Internal — менее строгие SLA, фокус на функциональность;
  • runbooks per surface отличаются.

Ось 2 → Ось 6 (Реализация)​

Связь: текущая реализация имеет частичное покрытие поверхностей.

Главные пробелы:

  • Partner API Surface — не реализована (текущий https://api.vitrip.store/stuba — это adapter ingestion, не Partner API);
  • Tour Builder Closed Surface — не реализована;
  • Agency Working Surface — не реализована;
  • Internal Operational Surface — частично через admin-панель vitrip.store;
  • B2C Storefront Surface — частично через vitrip.store сайт.

Ось 3 (Платформа как продукт) → другие оси​

Ось 3 → Ось 1​

Связь: продуктовые тарифы реализуются через политики (policy_set) на Tenant-сущности.

Главные правила:

  • структура tier — это policy_set с capabilities и envelope;
  • caps and quotas per tier — это quota_definition сущности;
  • billing — это billing_entry сущности с трассой к usage_event.

Ось 3 → Ось 2​

Связь: тарифы определяют, какие поверхности доступны и в каком объёме.

Главные правила:

  • Free tier → только sandbox + ограниченный Partner API;
  • Starter tier → production Partner API с минимальными квотами;
  • Professional tier → Partner API + Tour Builder;
  • Enterprise tier → все поверхности + dedicated infrastructure (фаза 4).

Ось 3 → Ось 4 (Данные и интеллект)​

Связь: динамическая тарификация опирается на metering данных.

Главные правила:

  • usage metering — базовый источник для тарификации;
  • tracking events на Partner API — материал для billing;
  • ML может использоваться для динамического ценообразования (фаза 3+);
  • partner-facing analytics product — часть Professional/Enterprise tiers.

Ось 3 → Ось 5 (Операционная)​

Связь: SLA — операционное обещание, прямо зависит от тарифа.

Главные правила:

  • SLA per tier — формальный коммерческий контракт;
  • credits at SLA breach — автоматические для Professional+;
  • capacity envelopes per tier — операционная гарантия для Enterprise;
  • DR с RTO/RPO — обязательство Enterprise tier;
  • on-call rotation для critical issues — Enterprise tier;
  • dedicated infrastructure — Enterprise tier на фазе 4.

Ось 3 → Ось 6 (Реализация)​

Связь: платформа как продукт — не реализована в текущем home-to-go-api.

Главные пробелы:

  • нет tariff tiers;
  • нет sandbox с реалистичными mock-данными;
  • нет certification flow;
  • нет partner billing console;
  • нет SLA-контракта;
  • нет partner-facing analytics product.

Полная разработка — фазы 2-4.

Ось 4 (Данные и интеллект) → другие оси​

Ось 4 → Ось 1​

Связь: events — трансляция изменений каноничных сущностей; ML использует canonical entities как источники features.

Главные правила:

  • domain events не существуют без каноничных сущностей;
  • analytical events наблюдают поведение вокруг каноничных сущностей;
  • features в feature store — derived from canonical entities + events;
  • replay capability требует стабильной идентичности каноничных сущностей.

Ось 4 → Ось 2​

Связь: tracking events на поверхностях — материал для аналитики.

Главные правила:

  • B2C — самый интенсивный источник;
  • Partner API — usage metering для тарификации;
  • privacy boundary различная per surface;
  • consent management для cookies на B2C — обязательное условие захвата events.

Ось 4 → Ось 3​

Связь: аналитика — продукт для tenants Professional+ tier.

Главные правила:

  • partner-facing dashboards — часть Professional/Enterprise tiers;
  • анонимизированные benchmarks — часть Enterprise tier;
  • raw event access — не предоставляется ни одному tier (только агрегаты).

Ось 4 → Ось 5 (Операционная)​

Связь: observability metrics — пересечение с data осью.

Главные правила:

  • operational metrics в analytical pipelines;
  • anomaly detection в ingestion — operational use case ML;
  • predictive scaling — основан на ML моделях;
  • alerting на основе ML detection;
  • post-incident analysis использует event log из DWH.

Ось 4 → Ось 6 (Реализация)​

Связь: текущий events_themes — первая итерация event capture.

Главные пробелы:

  • events_themes смешивает domain events и analytical events;
  • нет полноценного DWH;
  • нет ML platform;
  • нет A/B testing framework.

Ось 5 (Операционная) → другие оси​

Ось 5 → Ось 1​

Связь: операционные требования влияют на жизненные циклы каноничных сущностей.

Главные правила:

  • audit-grade durability требует append-only event journal для критических сущностей;
  • recovery procedures для unknown_external_state в Booking — first-class;
  • replay capability — определяет, как persistent layer проектируется.

Ось 5 → Ось 2​

Связь: operational requirements per surface.

Главные правила:

  • B2C — самый жёсткий по latency и uptime;
  • Partner API — самый жёсткий по contract stability;
  • Internal — менее строгий, фокус на функциональность.

Ось 5 → Ось 3​

Связь: operational SLA = коммерческое обещание.

Главные правила:

  • 99.9% uptime — обещание Enterprise tier;
  • credits — формальный механизм возмещения при breach;
  • capacity envelopes — операционная гарантия Enterprise tier;
  • DR — обязательство Enterprise tier.

Ось 5 → Ось 4​

Связь: observability — operational перспектива data оси.

Главные правила:

  • metrics, traces, logs — основа observability;
  • correlation через trace IDs — основа для cross-service debug;
  • alerting на основе доменных метрик (active quotes, pending bookings, settlement event lag);
  • partner-facing dashboards — операционная видимость как часть продукта.

Ось 5 → Ось 6 (Реализация)​

Связь: текущая инфраструктура — фаза Bootstrap операционной оси.

Главные пробелы:

  • managed PostgreSQL vitianaapipg.psql.tools — внешний провайдер, миграция в OVHcloud в фазе 1;
  • нет multi-region;
  • нет formal DR plan, RTO/RPO;
  • нет formal incident management;
  • нет 24/7 on-call.

Ось 6 (Реализация) → другие оси​

Ось 6 → Все остальные оси​

Связь: текущая реализация определяет starting point для каждой оси.

Главные принципы:

  • canonical model (ось 1) рефакторится поверх существующих таблиц home-to-go-api;
  • поверхности (ось 2) разворачиваются параллельно с сохранением vitrip.store сайта в production;
  • продуктовые компоненты (ось 3) разрабатываются с нуля — текущая реализация не имеет product-as-product атрибутов;
  • data ось (ось 4) разрабатывается с нуля — events_themes — первая итерация без разделения domain/analytical;
  • операционная ось (ось 5) — постепенная миграция от текущего внешнего managed PostgreSQL к OVHcloud-первичной экосистеме.

Полная карта — в overview/relation-to-implementation-baseline.md.

Кросс-осевые контуры​

Некоторые контуры платформы проходят через несколько осей одновременно. Этот раздел описывает их.

Кросс-осевой контур 1. Контур приёма данных от поставщика​

Оси: 1 (canonical entities) + 2 (Internal Operational + S2S surfaces) + 4 (events) + 5 (operational reliability) + 6 (implementation).

Что происходит:

  • supplier sends data through API or webhook → ось 6 (текущий Stuba module);
  • ingestion adapter normalizes → ось 1 (canonical entities create);
  • changes captured as domain events → ось 4 (event bus);
  • observability tracks ingestion lag → ось 5 (operational metrics);
  • governance reviews anomalies → ось 1 (governance layer);
  • canonical changes propagate to surfaces → ось 2 (publication contour).

Главное правило кросс-осевой целостности: изменение в любой части цепочки должно учитывать всю цепочку. Например, добавление нового поставщика в ось 6 требует:

  • расширения SupplierCapabilityProfile (ось 1);
  • адаптации ingestion adapter без изменения canonical model (ось 1);
  • добавления supplier-specific events (ось 4);
  • обновления observability dashboards (ось 5);
  • обновления supplier capability matrix в [reference/suppliers.md] (ось 6).

Кросс-осевой контур 2. Контур продажи туристического продукта​

Оси: 1 (Property → Offer → Quote → Booking) + 2 (B2C / Agency / Partner surfaces) + 3 (commercial pricing per tier) + 4 (conversion tracking + ML ranking) + 5 (operational reliability for booking commit) + 6 (текущая реализация Stuba booking).

Что происходит:

  • user searches → tracking event → search projection (ось 4) ranked by ML (ось 4);
  • offer rendered with surface-aware visibility (ось 2);
  • user creates quote → commercial policy applied (ось 3);
  • booking commit → transactional layer (ось 1) → settlement events generated (ось 1);
  • partner notification through webhook (ось 2 + ось 4);
  • partner billing entry created (ось 3 + ось 4);
  • operational metrics emitted (ось 5).

Кросс-осевой контур 3. Контур композиции тура​

Оси: 1 (composition entities) + 2 (Tour Builder Closed Surface) + 3 (paid Tour Builder tier) + 4 (composition analytics + ML compatibility) + 5 (Tour Builder SLA) + 6 (нет реализации, разработка в фазах 2-3).

Что происходит:

  • agent or partner authoring tour → Tour Builder Closed Surface (ось 2);
  • composition primitives invoked (ось 1: TourDraft entities);
  • compatibility check via ML (ось 4: ML inference);
  • repricing/revalidation (ось 1: operational layer + ось 4: events);
  • proposal published as artifact (ось 1: ProposalArtifact);
  • proposal versioned with history (ось 1: ProposalVersion);
  • conversion to bookings (ось 1: bookings linked to ProposalVersion);
  • billing for Tour Builder operations (ось 3 + ось 4).

Кросс-осевой контур 4. Контур динамической тарификации партнёра​

Оси: 3 (продуктовая модель) + 4 (metering и аналитика) + 5 (operational SLA) + 1 (UsageEvent + BillingEntry) + 2 (Partner API Surface).

Что происходит:

  • partner makes API call → tracking event → metering pipeline (ось 4);
  • usage aggregated per period (ось 4);
  • billing entry generated based on tier (ось 3);
  • quota state updated (ось 1: QuotaState);
  • partner-facing dashboard shows usage (ось 3 + ось 4);
  • alerts on approaching limits (ось 5);
  • self-service tier upgrade (ось 3).

Кросс-осевой контур 5. Контур публикации с проверкой целостности​

Оси: 1 (Offer Integrity, governance) + 2 (publication per surface) + 4 (publication events) + 5 (operational visibility) + 6 (нет реализации).

Что происходит:

  • offer materialized (ось 1);
  • integrity gating runs (ось 1: integrity check + governance);
  • governance review if anomaly detected (ось 1: ReviewCase);
  • publication state set (ось 1: PublicationState);
  • per-surface visibility computed (ось 2);
  • offer.publication.allowed event emitted (ось 4);
  • search projection updated (ось 4);
  • operational dashboards show publication state (ось 5).

Кросс-осевой контур 6. Контур восстановления после аварии​

Оси: 5 (operational DR) + 1 (canonical recovery) + 4 (replay capability) + 3 (SLA credits) + 6 (current state of recovery in production).

Что происходит:

  • incident occurs (ось 5);
  • runbook executed by on-call (ось 5);
  • if data loss: restore from backup (ось 5: DR + ось 1: canonical entities);
  • if events lost: replay from event log (ось 4: replay capability + ось 1: replay-friendly entities);
  • communication to affected tenants (ось 3 + ось 5);
  • SLA breach calculation, credits issued (ось 3);
  • post-mortem with action items (ось 5);
  • improvements deployed (ось 5: release engineering).

Правила кросс-осевых решений​

Правило 1. Изменение в одной оси требует проверки всех связанных осей​

При изменении любой каноничной сущности (ось 1) — обязательная проверка:

  • видимости на поверхностях (ось 2);
  • импакт на продуктовые тарифы (ось 3);
  • генерации событий (ось 4);
  • операционных требований (ось 5);
  • технического долга в реализации (ось 6).

Правило 2. Тарифные изменения каскадируют​

Изменение Free / Starter / Professional / Enterprise envelope (ось 3) требует:

  • обновления policy_set сущностей (ось 1);
  • обновления visibility и rate limits на поверхностях (ось 2);
  • обновления metering rules (ось 4);
  • обновления SLA contracts (ось 5).

Правило 3. Операционные SLA каскадируют​

Изменение SLA target (ось 5) требует:

  • проверки capacity (ось 5: capacity planning);
  • проверки tariff impact (ось 3: SLA — часть продукта);
  • проверки observability sufficiency (ось 4 + ось 5);
  • проверки текущей реализации на способность достичь target (ось 6).

Правило 4. Запуск нового domain event требует синхронизации​

Добавление нового domain event (ось 4) требует:

  • определения source canonical entity (ось 1);
  • определения consumers и их visibility (ось 2: webhook subscriptions per surface);
  • определения impact на тарификацию, если event monetizable (ось 3);
  • определения operational requirements для delivery (ось 5: webhook SLA);
  • проверки readiness в текущей реализации (ось 6).

Правило 5. Любое изменение в ось 6 — техническое решение​

Изменения в home-to-go-api (ось 6) — это технические решения реализации, не архитектурные. Архитектура (оси 1-5) — целевая модель; ось 6 — текущее состояние реализации.

При расхождении архитектура (оси 1-5) выигрывает. Расхождение фиксируется как технический долг ингестион-слоя, и план конвергенции — в overview/relation-to-implementation-baseline.md.

Граф зависимостей между документами осей​

Главная ось:
overview/index.md
   ↓ (читается первым)
overview/platform-vision-and-manifest.md (манифест переосмысления)
   ↓ (читается вторым)
overview/architectural-anchor-and-business-model.md (бизнес-модель)
   ↓ (опирается на якорь)

Шесть осей (читаются после главной оси):
   ↓
overview/canonical-domain-spine.md (ось 1) ←──┐
overview/layers.md (ось 2) ←──────────────────┤
overview/platform-as-product.md (ось 3) ←─────┤
overview/data-and-intelligence-spine.md (ось 4) ←──┤ Все 6 осей пересекаются
overview/operational-spine.md (ось 5) ←────────────┤ через этот документ
overview/relation-to-implementation-baseline.md (ось 6) ←──┘
   ↓ (карта пересечений)
overview/architectural-axes-and-cross-links.md (этот документ)
   ↓ (после прочтения переход вниз по слоям)

Документы второго круга (reference/) и операций (operations/) — детализация.

Использование этого документа в работе архитектора​

Этот документ используется как контрольный список при любом архитектурном решении:

При создании или изменении любого нового документа​

  1. Идентифицировать, к какой оси относится решение.
  2. Открыть этот документ и найти соответствующие пересечения.
  3. Проверить, нужно ли обновить документы других осей.
  4. Зафиксировать обновления через docs_patch_section или создать новые документы.
  5. Использовать docs_links для проверки целостности обратных ссылок.

При обнаружении противоречия между документами​

  1. Идентифицировать, в каких осях лежит противоречие.
  2. Применить правила:
    • правило 00000 (платформа над поставщиками) — высший приоритет;
    • правило 5 (ось 6 — техническое; оси 1-5 выигрывают);
    • тезисное обоснование решения.
  3. Если противоречие существенное — эскалировать пользователю.

При планировании следующего документа​

  1. Идентифицировать ось, к которой относится новый документ.
  2. Открыть этот документ — найти пересечения, которые должны быть отражены.
  3. Включить ссылки на пересекающиеся документы в новый документ.
  4. После создания — запустить docs_links для проверки graph integrity.

Связанная документация​

Все шесть осей с детальным раскрытием:

Документы второго круга, на которые опирается этот документ:

Архивные документы первичного слоя:

Уточнение под Фазы 4–6 (28.04.2026) — расширение карты пересечений с новыми доменами​

Документ опубликован 25.04.2026 как карта пересечений 6 архитектурных осей. После Фаз 4–6 опубликованы 16 новых каноничных документов, которые создают новые точки пересечения между осями. Эта секция фиксирует расширенную карту.

Ось 1 ↔ Ось 2 — новые пересечения​

Truth visibility matrix (см. reference/clients.md, Фаза 7) — каждая каноничная сущность Group 1–7 проявляется на 6 client surfaces с разной видимостью. Расширение через:

  • canonical entities ↔ Tour Builder Closed Surface — full composition primitives (см. tour-builder-operational-model.md);
  • transactional entities ↔ Partner Machine Surface — only contract-safe states (booking-state-machine 14 каноничных state names);
  • payment entities ↔ B2C Surface — presentation-safe (PSP-managed UI);
  • security/audit entities ↔ Internal Surface only (см. security-architecture.md).

Ось 1 ↔ Ось 3 — новые пересечения​

  • Tour Builder operational model (saga + drift + compensation) ↔ paid Tour Builder tier (Professional+);
  • payment-domain ↔ tier-зависимые PSP routing;
  • multi-tenant-isolation ↔ 3 уровня изоляции как commercial product attribute per tier;
  • compliance-and-legal ↔ regulated tenants → mandatory dedicated_infrastructure.

Ось 1 ↔ Ось 4 — новые пересечения​

  • booking-state-machine (14 состояний) → каждый transition генерирует domain event (at-least-once + ordered per entity);
  • Tour Builder saga → saga events class (exactly-once-effective);
  • governance decisions → отдельный operational events class;
  • IsolationBoundaryCheck → events class с alert hooks;
  • compliance events (DSR, consent, breach) → отдельный regulated class.

Ось 1 ↔ Ось 5 — новые пересечения​

  • booking unknown_external_state (8-е каноничное) → SLI 6 (target менее 1%);
  • Tour Builder saga compensation → SLI saga health;
  • payment success rate → SLI 7;
  • caнoнические incident classes (8 в runbooks) ← операционная реализация over canonical entities.

Ось 1 ↔ Ось 6 — новые пересечения​

  • Долг 1 (multi-tenancy migration) ← canonical Tenant entity vs current single-tenant apivitianadb;
  • Долг 2 (Stuba-shaped schema) ← canonical Property vs current hotels schema;
  • Долг 8 (events_themes mixed) ← canonical 6 classes events vs current single table.

Ось 2 ↔ Ось 3 — новые пересечения​

  • 6 surface contracts (layers.md) × 4 API tier (api-as-product.md) → матрица доступа:
    • Free: Internal (sandbox только) + Partner Machine (sandbox);
    • Starter: + B2C, + Partner Machine production;
    • Professional: + Agency Working, + Partner UI/SDK, + Tour Builder Closed;
    • Enterprise: + White-Label embedded.
  • Tour Builder Closed Surface — отдельный paid contract (не Partner API tier);
  • Partner UI/SDK Surface — peer для Partner Machine (правило 00000).

Ось 2 ↔ Ось 4 — новые пересечения​

Ось 2 ↔ Ось 5 — новые пересечения​

  • 6 client surfaces × 4 SLA tier → SLA matrix (см. sla-and-on-call-model.md);
  • canary deployment правило: Enterprise — first canary (counter-intuitive, но stripe/twilio practice);
  • white-label embedded — partner-defined SLA по контракту.

Ось 3 ↔ Ось 4 — новые пересечения​

  • usage metering → revenue stream partner_api_usage (см. api-metering-and-usage-governance.md);
  • partner-facing analytics → Professional+ tier feature (revenue stream);
  • ML-driven dynamic pricing → premium add-on (фаза 4+);
  • A/B testing для tier optimization.

Ось 3 ↔ Ось 5 — новые пересечения​

  • API tier ↔ SLA class:
    • Free → best-effort;
    • Starter → 95%;
    • Professional → 99%;
    • Enterprise → 99.9%+.
  • service credits как revenue correction (см. economic-model.md);
  • DR class per tier (Tier 1 для всех, dedicated_infrastructure для Enterprise);
  • on-call rotation структура (5 уровней) — operational cost для Enterprise.

Ось 4 ↔ Ось 5 — новые пересечения​

  • observability metrics ← analytical events;
  • SLI calculation ← Prometheus + custom domain metrics;
  • security audit log — отдельный stack (SIEM), не часть operational observability;
  • ML use case anomaly detection в ingestion ↔ runbooks supplier degradation;
  • ML use case supplier_health_prediction ↔ runbooks supplier suppression.

Ось 4 ↔ Ось 6 — новые пересечения​

  • Долг 8 (events_themes mixed) ← каноничные 6 classes events;
  • Долг 3 (no event-driven architecture) ← Redis Streams baseline (Phase 1) → NATS Jetstream (Phase 3);
  • ML platform — gap: отсутствует в home-to-go-api, разработка с нуля.

Ось 5 ↔ Ось 6 — новые пересечения​

  • 4 фазы инфраструктурного масштабирования (см. scaling-and-packaging-roadmap.md) ↔ текущая фаза 1 в home-to-go-api;
  • runbooks для Stuba supplier ↔ existing Stuba module operational behaviour;
  • DR posture: текущий managed PostgreSQL backup → upgrade до Tier 1 mandatory с фазы 2.

Каноничные cross-cutting concerns​

После Фаз 4–10 выделяются 3 cross-cutting concerns, проходящие через все 6 осей:

  1. Security & Audit (security-architecture.md) — IAM, encryption, secret lifecycle, audit log: pervasive across all axes;
  2. Compliance & Legal (compliance-and-legal.md) — GDPR, PSD2, EU TOMS, Package Travel Directive: применяется к каждому domain;
  3. Documentation Governance (documentation-governance.md) — каноничный процесс для всех документов всех осей.

Каноничный итог уточнения​

Граф пересечений теперь учитывает все 16 новых документов Фаз 4–6 + 5 архитектурных правил + 3 cross-cutting concerns. Это даёт более полную карту всех связей между осями платформы.

Основные источники истины пересечений:

Уточнение выполнено через no-destruction.