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

Обзор Ось 1 — Каноничная доменная ось (резюме простыми словами)

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

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

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

Цель резюме — чтобы любой грамотный читатель за 10–15 минут понял, о чём ось 1, какие у неё ключевые понятия, какие принципы и какие запреты.

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

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

Документ объясняет: какие понятия (сущности) являются главными, какие — производными, как они связаны, как меняются во времени и кто их видит на разных интерфейсах платформы.

Главный принцип​

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

Семь групп понятий​

Все понятия платформы делятся на семь групп. Каждая группа имеет свою роль, свой срок жизни и свои правила видимости.

Группа 1. Главные понятия (мастер-сущности)​

Долгоживущие понятия — основа платформы. Меняются редко и только через формальные процедуры управления данными.

  • Объект размещения (Property) — отель, апартамент, вилла. Стабильная карточка платформы.
  • Канонический продукт (CanonicalProduct) — единица продаж внутри объекта размещения (тип номера и т.п.).
  • Организация — родовое понятие для всех юридических сущностей.
  • Пользователь, партнёр, агентство — разновидности организаций и людей.
  • Набор политик (PolicySet) — правила работы (коммерческие, операционные).
  • Решение управления данными (GovernanceDecision) — формализованное решение модератора.

Группа 2. Понятия, производные от поставщиков​

Сырая информация от поставщиков, которая хранится отдельно от главной модели. Это «след» того, что прислал поставщик. Никогда не подменяет главные понятия.

  • Поставщик — внешний источник данных.
  • Объект поставщика (SupplierProperty) — представление объекта с точки зрения поставщика.
  • Продукт поставщика (SupplierProduct) — продаваемая единица у поставщика.
  • Сырая нагрузка (SupplierPayload) — то, что поставщик прислал в исходном виде.
  • Запуск синхронизации (SupplierSyncRun) — каждый сеанс получения данных.
  • Профиль возможностей поставщика — что он умеет давать.
  • Ссылка на бронирование у поставщика — идентификатор бронирования на его стороне.

Ключевое правило: эти понятия видны только во внутренних инструментах платформы, никогда не видны клиентам и партнёрам.

Группа 3. Операционные понятия предложения​

Краткоживущие понятия — то, что появляется во время поиска и подготовки бронирования.

  • Предложение (Offer) — конкретное предложение, годное к показу и бронированию.
  • Снимок доступности и цены (AvailabilitySnapshot, PriceSnapshot) — фиксация состояния на момент.
  • Коммерческая фиксация (Quote) — обещание цены конкретному клиенту в конкретный момент. Это не просто цена на карточке — это формально зафиксированное обещание.
  • Результат повторной проверки (RevalidationResult) — обновлённое состояние после проверки у поставщика.
  • Поисковая сессия — контекст конкретного поиска.

Группа 4. Транзакционные понятия​

Понятия, связанные с бронированием. Никогда не теряются, хранятся вечно (для аудита, споров, отчётности).

  • Бронирование (Booking) — подтверждённая или частично подтверждённая транзакция.
  • Элемент бронирования (BookingItem) — отдельная позиция внутри бронирования (один номер, один трансфер).
  • Событие в жизни бронирования (BookingEvent) — каждое изменение фиксируется отдельным событием.
  • Намерение платежа (PaymentIntent) — фиксация шага платежа.
  • Возврат (Refund) — финансовый возврат.
  • Запрос на изменение (AmendmentRequest) — запрос на правку бронирования.

Группа 5. Композиционные понятия (туры)​

Понятия конструктора туров — модульная сборка из множества компонентов.

  • Черновик тура (TourDraft) — рабочий, изменяемый набросок.
  • Элемент композиции — отдельный модуль внутри черновика.
  • Альтернативный вариант (DraftVariant) — альтернатива для элемента.
  • Коммерческое предложение тура (TourProposal) — опубликованная версия для клиента.
  • Версия предложения (ProposalVersion) — фиксированный снимок предложения.
  • Материализованный артефакт (ProposalArtifact) — итоговый PDF, ссылка для клиента.

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

Группа 6. Понятия управления и проверки данных​

Контур качества данных — кто и как принимает решения о данных.

  • Кейс проверки (ReviewCase) — задача для модератора.
  • Решение о маппинге — соответствие сущности поставщика канонической.
  • Решение о слиянии — как объединить данные от нескольких поставщиков.
  • Аномалия — обнаруженная странность в данных.
  • Происхождение поля (FieldLineage) — кто и когда внёс каждое значение.
  • Правило приоритета источника — какой источник важнее при конфликте.

Группа 7. Понятия пользователей, тенантов, доступа​

Понятия идентичности и прав доступа.

  • Тенант — изолированное пространство клиента (агентство, корпоративный заказчик).
  • Рабочее пространство — раздел внутри тенанта.
  • Назначение роли — связь пользователя с ролью.
  • Выданное право (CapabilityGrant) — конкретное разрешение.
  • API-клиент и его учётные данные — для машинных интеграций.
  • Рабочий контекст актора (ActorContext) — текущая роль пользователя (один пользователь может выступать в разных ролях).

Ключевой принцип: идентичность («кто»), тенант («где»), право («что») и контракт («как») — четыре разных понятия. Никогда не сливать их в одну роль или один тип пользователя.

Десять рабочих контуров​

Понятия объединяются в рабочие контуры — операционные процессы, в которых участвуют разные группы:

  1. Контур приёма данных — как сырые данные поставщиков превращаются в канонические записи.
  2. Контур поиска — как пользователи находят предложения.
  3. Контур фиксации обещаний — как из найденного предложения возникает зафиксированная цена.
  4. Контур транзакционного коммита — как обещание превращается в подтверждённое бронирование.
  5. Контур пост-продажи — отмены, изменения, возвраты, споры.
  6. Контур композиции тура — сборка туров из компонентов.
  7. Контур взаиморасчётов — деньги между платформой, поставщиками, партнёрами.
  8. Контур управления данными — модерация, разрешение конфликтов.
  9. Контур учёта потребления — учёт нагрузки на платформу для тарификации.
  10. Контур наблюдаемости — мониторинг, метрики, журналы.

Матрица видимости​

Каждая группа понятий по-разному видна на разных интерфейсах платформы:

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

Политики свежести​

У каждой группы своё допустимое «старение» информации:

  • Главные понятия — могут быть актуальны дни или часы.
  • Понятия поставщиков — минуты-часы, обновляются при каждом сеансе.
  • Операционные предложения — минуты, проверяются перед каждой коммерческой фиксацией.
  • Коммерческая фиксация — действует только на свой срок жизни (validity window).
  • Транзакции и управление — никогда не устаревают (вечный аудит).
  • Идентичность — обновляется по административным действиям.

Семнадцать ключевых запретов смешения понятий​

Каноничный список того, что нельзя путать:

  • Объект размещения (Property) и предложение (Offer) — стабильное и операционное.
  • Объект поставщика и канонический объект — два разных слоя.
  • Канонический продукт и продукт поставщика.
  • Предложение (Offer) и коммерческая фиксация (Quote) — возможность и формальное обещание.
  • Коммерческая фиксация (Quote) и бронирование (Booking) — обещание и транзакция.
  • Черновик тура и опубликованное предложение тура.
  • Опубликованное предложение тура и его материализованный артефакт.
  • Идентичность пользователя и его рабочий контекст.
  • Партнёр и агентство — разные коммерческие категории.
  • Истина поставщика и каноничная истина платформы — никогда не смешивать.
  • Кешированный предпросмотр и состояние, готовое к коммиту.
  • Срок коммерческой фиксации и срок операционной актуальности.
  • Подтверждение поставщика и подтверждение платформы — успех у поставщика не равен успеху в каноничном слое.
  • Известный отказ и неопределённое внешнее состояние.
  • Отображаемая цена и зафиксированная цена.
  • Зафиксированная цена и реальная цена расчёта.
  • Коммерческая фиксация и транзакционный коммит.

Каноничные четырнадцать состояний бронирования​

Бронирование живёт в одном из четырнадцати состояний (формализовано отдельным документом):

  1. draft — черновик, не отправлен.
  2. submitted — отправлен, идут предварительные проверки.
  3. pending_revalidation — ожидание повторной проверки у поставщика.
  4. pending_supplier_confirmation — ожидание ответа поставщика.
  5. supplier_confirmed — поставщик подтвердил.
  6. platform_confirmed — платформа финализировала (для внешних — это «подтверждено»).
  7. partially_confirmed — поставщик подтвердил часть позиций.
  8. unknown_external_state — поставщик не отвечает (целевая доля менее одного процента).
  9. failed — известный отказ.
  10. cancel_requested — запрошена отмена.
  11. cancel_in_progress_supplier — отмена выполняется у поставщика.
  12. cancelled — отменено.
  13. amendment_in_progress — выполняется изменение.
  14. completed — исполнено.

Связь с шестью осями архитектуры​

Каноничная модель проявляется на других пяти осях:

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

Связь с реальной реализацией​

В уже работающем коде существующей реализации сейчас:

  • Главные понятия — есть как первая итерация в схеме hotels, требует унификации для нескольких поставщиков.
  • Понятия поставщиков — пока живут как поля supplier_* в общей таблице, нужно вынести в отдельный слой.
  • Операционные предложения, транзакции, туры, управление, учёт, наблюдаемость — пока не реализованы, требуют разработки на следующих фазах.
  • Идентичность и тенантность — есть как 18 таблиц usr_*, требует ревью под мульти-тенантную модель.

Что нельзя делать с этой моделью​

  • Подстраивать каноничные поля под структуру конкретного поставщика.
  • Использовать идентификатор отеля или типа номера как идентификатор транзакции.
  • Сливать в одно сущности коммерческой фиксации и бронирования.
  • Сливать в одно черновик тура и опубликованное предложение.
  • Сливать в одно пользователя и его рабочий контекст.
  • Сливать в одно партнёра и агентство.
  • Хранить сырые данные поставщиков в одной таблице с каноническими.
  • Терять происхождение полей при обновлении.
  • Допускать видимость сырых данных поставщиков на внешних интерфейсах.

Итог​

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

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