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

Обзор Граф пересечений архитектурных осей (резюме простыми словами)

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

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

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

Цель резюме — чтобы любой грамотный читатель за 10–15 минут понял, как шесть осей платформы связаны друг с другом, почему они не существуют отдельно, какие сценарии бизнеса проходят сразу через несколько осей, и какие правила нужно соблюдать при изменениях в одной из них.

О чём документ​

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

Простыми словами: это «карта переплетений». Шесть осей платформы — каноничные понятия, поверхности взаимодействия, продукт, данные и интеллект, операционная зрелость, связь с реализацией — кажутся независимыми, но на самом деле тесно переплетены. Изменение в одной оси неизбежно требует учёта других. Этот документ показывает, где именно проходят эти связи и какие правила соблюдать при изменениях.

Документ объясняет: архитектура платформы — это не шесть параллельных миров, а единая система с явными точками связи. Понимание этих точек — необходимое условие для целостных архитектурных решений. Без карты пересечений можно «починить» одну ось и одновременно «сломать» три другие, не заметив этого.

Зачем нужна карта пересечений​

Простой пример из жизни. Допустим, мы решаем добавить в платформу новый тарифный план «Стартап» между бесплатным и стартовым тарифами.

На первый взгляд — это решение третьей оси (платформа как продукт). Поменяли тарифную сетку, и всё.

На самом деле это решение тянет за собой:

  • Каноничную доменную ось — в платформе появляется новый тип политик и квот; нужно фиксировать как новые поля у понятия тенанта.
  • Поверхности взаимодействия — что доступно стартап-клиентам в партнёрском интерфейсе, какие лимиты, какие webhook-уведомления.
  • Ось данных и интеллекта — учёт потребления для нового тарифа должен попасть в аналитику и счета.
  • Операционную ось — какое соглашение об уровне обслуживания обещаем стартап-клиентам, как это влияет на дежурства и план восстановления.
  • Связь с реализацией — что в существующей реализации нужно дополнить, чтобы поддержать новый тариф.

Без явной карты пересечений архитектор может поменять только тарифную сетку и не заметить остальных пяти затронутых осей — это создаёт скрытый разрыв между документами и потом проявляется как противоречия в реализации, проблемы с сертификацией партнёров, сбои в учёте потребления.

Шесть осей — короткое напоминание​

ОсьНазваниеГлавный фокус
1Каноничная доменнаяПонятия и сущности платформы, их жизненные циклы
2Поверхности взаимодействияДвери платформы к миру, контракты с разными сторонами
3Платформа как продуктТарифы, тарификация, опыт разработчика, обещания обслуживания
4Данные и интеллектСобытия, аналитика, машинное обучение, эксперименты
5ОперационнаяМасштабирование, надёжность, инциденты, релизы
6Связь с реализациейЧто уже работает, технический долг, путь конвергенции

Подробнее каждая ось — в соответствующем резюме (см. ссылки в конце документа).

Десять главных пересечений между осями​

Между осями есть много мелких связей, но десять из них — главные и наиболее частые в работе.

1. Каноничные понятия → Поверхности взаимодействия​

Одно и то же понятие платформы (например, «коммерческая фиксация») существует в одном экземпляре, но по-разному видно на разных дверях. Внутренний оператор видит всю историю применения политик. Агент — структуру цены и применённую политику. Партнёр — только контракт-безопасные суммы. Конечный клиент — только итоговую цену.

Главное правило: одна сущность, разная видимость per surface. Видимость — часть контракта поверхности, а не runtime-фильтр.

2. Каноничные понятия → Платформа как продукт​

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

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

3. Каноничные понятия → Данные и интеллект​

Все каноничные сущности порождают доменные события — это «что-то случилось внутри платформы». Аналитические события наблюдают поведение вокруг каноничных сущностей. Признаки для машинного обучения выводятся из каноничных сущностей и событий. Возможность повторного воспроизведения работает потому что у каноничных сущностей стабильная идентичность.

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

4. Каноничные понятия → Операционная​

Жизненный цикл сущностей определяет операционные требования. Бронирование — самый критичный операционный домен (вечный аудит, процедуры восстановления, обещания обслуживания per тариф). Управление данными — операционный процесс с человеком в цикле. Состояние «неопределённое внешнее состояние» в жизненном цикле бронирования — первоклассная операционная категория, требующая инструкции реагирования.

Главное правило: транзакционный слой — самое жёсткое обещание обслуживания (99,9%+ для корпоративного тарифа).

5. Поверхности взаимодействия → Платформа как продукт​

Поверхности — это продуктовые поверхности с разными коммерческими моделями. Партнёрский интерфейс — главный продукт B2B-маркетплейса. Закрытая поверхность конструктора туров — отдельный премиум-продукт со своим тарифом. Витрина для конечных клиентов — собственный канал плюс демонстрация возможностей платформы.

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

6. Поверхности взаимодействия → Данные и интеллект​

Каждая дверь — источник аналитических событий. Витрина для клиентов — самый интенсивный источник для анализа конверсии. Партнёрский интерфейс — учёт потребления для динамической тарификации. Агентская — рабочая аналитика для агентов. Конструктор туров — аналитика композиций для машинного обучения совместимости компонентов.

Главное правило: граница приватности у каждой двери своя; согласие на использование cookie на витрине для клиентов — обязательное условие захвата событий.

7. Платформа как продукт → Операционная​

Соглашение об уровне обслуживания — формальное коммерческое обещание тенанту, прямо зависящее от тарифа. Кредиты при нарушении обещания — автоматические для профессионального и корпоративного тарифов. Гарантированная мощность — операционная гарантия для корпоративного тарифа. План восстановления с целевыми показателями — обязательство корпоративного тарифа.

Главное правило: обещание обслуживания и тариф — две стороны одной монеты. Изменение тарифа меняет обещание.

8. Данные и интеллект → Операционная​

Наблюдаемость — операционная сторона оси данных. Метрики, трассы, журналы — основа наблюдаемости. Корреляция через идентификаторы трасс — основа для отладки между сервисами. Оповещения работают на доменных метриках (активные коммерческие фиксации, ожидающие бронирования, отставание событий взаиморасчётов). Партнёрские дашборды — операционная видимость как часть продукта.

Главное правило: обнаружение аномалий в приёме данных — операционный случай применения машинного обучения; предиктивное масштабирование основано на моделях.

9. Платформа как продукт → Данные и интеллект​

Партнёрская аналитика — продукт для тенантов профессионального тарифа и выше. Анонимизированные сравнительные показатели по сегменту — часть корпоративного тарифа. Сырой доступ к событиям не предоставляется ни одному тарифу — только сводки. Машинное обучение работает на динамическое ценообразование. Каркас A/B-тестирования — возможность для оптимизации продукта.

Главное правило: аналитика — это продукт, не «свободный доступ к данным».

10. Связь с реализацией → Все остальные оси​

Существующая реализация определяет точку старта для каждой оси. Каноничная модель строится поверх существующих таблиц с разделением каноничного и поставщикового. Поверхности разворачиваются параллельно с сохранением текущего сайта в боевой эксплуатации. Продуктовые компоненты разрабатываются с нуля. Ось данных перестраивается с разделением событий. Операционная — постепенная миграция от текущего стороннего управляемого хранилища к основному провайдеру.

Главное правило: при расхождении каноничная модель (оси 1-5) выигрывает; ось 6 фиксирует расхождение как технический долг с явным путём конвергенции.

Шесть рабочих сценариев, проходящих сразу через несколько осей​

Это самый практичный материал документа: реальные деловые сценарии, в которых задействованы сразу несколько осей.

Сценарий 1. Подключение нового поставщика данных​

Какие оси задействованы: все шесть.

Что происходит: поставщик присылает данные через свой программный интерфейс или асинхронные уведомления; адаптер приёма нормализует их в каноничные сущности; изменения захватываются как доменные события; наблюдаемость отслеживает отставание приёма; управление данными разбирает аномалии; каноничные изменения распространяются на поверхности через контур публикации.

Главное правило целостности: добавление нового поставщика не требует изменения каноничной модели — только новый адаптер. Это прямо следует из правила 00000 (платформа главная, поставщик — точка входа).

Сценарий 2. Продажа туристического продукта​

Какие оси задействованы: все шесть.

Что происходит: пользователь выполняет поиск (захват события, поисковая проекция, ранжирование машинным обучением); предложение отрисовывается с учётом видимости конкретной двери; пользователь создаёт коммерческую фиксацию (применяется коммерческая политика тарифа); фиксация бронирования (транзакционный слой, генерация событий взаиморасчётов); партнёр получает уведомление через webhook; запись биллинга создаётся с учётом тарифа партнёра; операционные метрики выпускаются.

Что показывает: даже самая базовая операция платформы — продажа отеля или тура — затрагивает все шесть осей одновременно.

Сценарий 3. Композиция тура​

Какие оси задействованы: все шесть, с особым акцентом на закрытую поверхность конструктора туров и платный тариф.

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

Что показывает: конструктор туров — это полноценный кросс-осевой контур, а не «надстройка над поиском отелей».

Сценарий 4. Динамическая тарификация партнёра​

Какие оси задействованы: платформа как продукт, данные и интеллект, операционная, каноничная доменная, поверхности.

Что происходит: партнёр делает вызов программного интерфейса; событие потребления попадает в конвейер учёта; потребление агрегируется за период; запись биллинга формируется на основе тарифа; обновляется состояние квоты; партнёрский дашборд показывает потребление в реальном времени; оповещения о приближении к лимитам; самостоятельное повышение тарифа.

Что показывает: прозрачная тарификация требует слаженной работы пяти осей одновременно.

Сценарий 5. Публикация предложения с проверкой целостности​

Какие оси задействованы: каноничная доменная, поверхности, данные и интеллект, операционная.

Что происходит: предложение материализуется; запускается проверка целостности (контроль качества, управление данными); если обнаружена аномалия — создаётся кейс модерации; устанавливается состояние публикации; вычисляется видимость для каждой поверхности; генерируется событие «предложение разрешено к публикации»; обновляется поисковая проекция; операционные дашборды показывают состояние публикации.

Что показывает: даже простая операция «показать предложение» — это связный контур с явными воротами качества.

Сценарий 6. Восстановление после аварии​

Какие оси задействованы: все шесть.

Что происходит: возникает инцидент; дежурный выполняет инструкцию реагирования; при потере данных — восстановление из резервной копии; при потере событий — повторное воспроизведение из журнала событий; коммуникация с затронутыми тенантами; расчёт нарушения соглашения об уровне обслуживания, выпуск компенсаций; постмортем с конкретными шагами; улучшения развёртываются через релизную инженерию.

Что показывает: один реальный инцидент задействует все шесть осей в течение часов или дней — от обнаружения через метрики до возмещения тенантам через коммерческую модель.

Пять каскадных правил для архитектурных решений​

Когда что-то меняется в одной оси, эти правила говорят, какие другие оси нужно проверить.

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

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

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

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

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

Изменение лимитов или содержания тарифов (ось 3) требует:

  • обновления политик (ось 1);
  • обновления видимости и ограничений скорости на поверхностях (ось 2);
  • обновления правил учёта потребления (ось 4);
  • обновления соглашений об уровне обслуживания (ось 5).

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

Изменение цели обещания обслуживания (ось 5) требует:

  • проверки доступной мощности (планирование вместимости);
  • проверки влияния на тариф — обещание это часть продукта (ось 3);
  • проверки достаточности наблюдаемости (ось 4);
  • проверки текущей реализации на способность достичь цели (ось 6).

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

Добавление нового доменного события (ось 4) требует:

  • определения исходной каноничной сущности (ось 1);
  • определения потребителей и их видимости (ось 2: подписки на webhook'и per surface);
  • определения влияния на тарификацию (если событие монетизируется) (ось 3);
  • определения операционных требований доставки (ось 5: обещание обслуживания webhook'ов);
  • проверки готовности существующей реализации (ось 6).

Правило 5. Каноничная модель выигрывает при расхождении​

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

При расхождении: архитектура выигрывает. Расхождение фиксируется как технический долг с явным путём конвергенции. Это прямое применение правила 00000 (платформа над поставщиками) к работе с существующей реализацией.

Три сквозных контура​

Кроме шести осей, через всю архитектуру платформы проходят три сквозные темы, которые касаются каждой оси одновременно:

  1. Безопасность и аудит — управление идентичностью, шифрование, жизненный цикл секретов, журнал аудита. Касается каждой оси: каноничные сущности должны иметь journal, поверхности — аутентификацию, продукт — двухфакторную аутентификацию для администраторов, данные — анонимизацию персональных данных, операционная — журналирование событий безопасности, реализация — миграцию на менеджер секретов.

  2. Соответствие регуляторам — GDPR, регуляции платёжных услуг, налоговые директивы, директивы пакетных путешествий. Касается каждой оси: каноничные сущности должны поддерживать запросы субъектов данных, поверхности — управление согласием, продукт — соглашения об обработке данных с партнёрами, данные — политики хранения, операционная — обработку нарушений, реализация — соответствие при работе с существующими данными.

  3. Управление документацией — каноничный процесс работы со всеми документами всех осей. Это сама дисциплина того, как создаётся и поддерживается архитектура.

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

Как использовать карту пересечений​

При любом архитектурном решении полезно задать четыре вопроса:

  1. К какой оси относится это решение?
  2. Какие из десяти главных пересечений оно затрагивает?
  3. Не попадает ли решение в один из шести кросс-осевых сценариев?
  4. Какое из пяти каскадных правил нужно соблюсти?

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

Что нельзя делать с этой картой​

  • Считать оси независимыми и менять одну без проверки других — это создаёт скрытые разрывы между документами.
  • Игнорировать обратные связи — например, если меняется поверхность, это может потребовать изменения каноничной сущности, не наоборот.
  • Принимать архитектурные решения только в одной оси без рассмотрения каскадных последствий.
  • Считать сквозные контуры (безопасность, соответствие регуляторам, управление документацией) отдельными осями — они проходят через всё.
  • Считать существующую реализацию (ось 6) «равноправной» с другими осями — она следует за архитектурой, а не диктует её.

Итог​

Документ закрепляет карту переплетений шести архитектурных осей платформы. Главное послание простое: архитектура — единая система, не шесть параллельных миров. Любое серьёзное изменение в платформе затрагивает несколько осей одновременно, и игнорирование этих связей создаёт скрытые расхождения между документами и реализацией. Каждый деловой сценарий (продажа тура, тарификация партнёра, инцидент) проходит сразу через несколько осей, и понимание этих контуров — необходимое условие для целостной работы. Десять главных пересечений, шесть рабочих сценариев и пять каскадных правил вместе образуют рабочий компас архитектора, обеспечивающий что архитектура остаётся согласованной, даже когда мир меняется.

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