Business Services — Сервисная декомпозиция платформы

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

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

Этот документ фиксирует не просто список микросервисов, а сервисную логику платформы vitrip.store, выведенную из её канонического доменного ядра.

Его задача — ответить на вопросы:

• какие сервисные контуры реально нужны платформе;
• какие из них являются центральными, а какие вспомогательными;
• где проходят границы ответственности;
• какие состояния и решения должны оставаться внутри домена, а какие могут быть вынесены в отдельные runtime-компоненты;
• как сервисная декомпозиция соотносится с truth policy, offer model, booking lifecycle, Tour Builder и коммерческим контуром.

Этот документ не следует читать как финальный deployment blueprint. Это документ о смысловой декомпозиции сервисов, а не о том, сколько именно контейнеров или pod-ов будет запущено в первой версии.

Опорные документы

Этот документ опирается на следующие материалы:

• Архитектурная основа платформы vitrip.store
• Главные выводы и проблемные зоны платформы
• Documentation Master Plan — Project 15 Structure Snapshot
• Codex Architecture Review — Vitiana API Platform
• Database Schema — PostgreSQL Design
• Storage Layer — Слой хранения данных
• Ingestion Layer — Слой приёма и обработки
• Commercial Model — Коммерческая модель, цена, settlement и канальные условия
• Partner Finance And Clearing — Балансы, лимиты, взаиморасчёты и финансовая дисциплина партнёров
• Post-Booking Lifecycle — Изменения, отмены, инциденты и сопровождение после продажи
• Tenant Configuration And Enablement — Тенантная настройка, policy и ввод в эксплуатацию
• API Metering And Usage Governance — Учёт потребления, квоты и дисциплина использования
• Offer Integrity And Publication Control — Целостность предложения и правила публикации
• API Contracts — OpenAPI 3.0 Specifications
• Clients Layer — Слой клиентов

Что Этот Документ Исправляет По Сравнению Со Старым Подходом

Старая версия документа мыслила сервисный слой слишком рано и слишком конкретно:

• через 4 заранее зафиксированных микросервиса;
• через hotel-centric модель;
• через прямую сцепку hotel_id / room_type / price / booking;
• через слишком раннюю уверенность в Go + gRPC + NATS как уже окончательной форме;
• через Tour Builder как красивый сервис, а не как ещё не оформленный домен.

Новый подход исходит из другой логики:

1. сначала domain boundaries;
2. потом service responsibilities;
3. потом synchronous and asynchronous interactions;
4. потом external and internal surfaces;
5. только после этого runtime topology.

Что Такое Business Services В Контексте Платформы

Business Services — это не просто backend-функции и не просто “модули между API и БД”.

В контексте этой платформы Business Services — это слой, в котором:

• каноническая доменная модель превращается в управляемое поведение системы;
• supplier data связываются с canonical entities и operational decisions;
• search, pricing, quote, booking и tour composition приобретают формальную логику;
• внутренние и внешние surface areas получают управляемые capabilities;
• критические operational flows получают устойчивые и объяснимые правила;
• платформа остаётся platform-core, а не сыпется в набор loosely-related endpoints.

Именно здесь платформенная идея либо становится промышленной системой, либо распадается на набор неудобно связанных частей.

Главный Принцип Декомпозиции

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

1. Где живёт canonical truth?
2. Где рождается offer?
3. Где происходит коммерческая интерпретация цены?
4. Где подтверждается booking?
5. Где собирается тур как продукт?
6. Где живёт tenancy, identity и policy model?
7. Где происходят governance и manual review?
8. Где фиксируется quote как коммерческое обещание?
9. Где живут settlement semantics и channel-aware commercial rules?
10. Где живут partner clearing и financial exposure controls?
11. Где живёт post-booking case reality?
12. Где выражается tenant-specific platform configuration?
13. Где живёт usage governance for external surfaces?
14. Где проходит integrity gate before quote and publication?

Если два процесса требуют разной truth policy, разного lifecycle или разной модели ошибок, они не должны безоговорочно сливаться в один сервис только ради “простоты”.

Сервисная Карта Платформы

На текущем этапе платформу разумно проектировать не вокруг четырёх сервисов, а вокруг набора сервисных контуров.

Ниже — рекомендуемая сервисная карта второго слоя.

1. Inventory Service

Контур канонического inventory и стабильного описания объекта размещения.

Основная ответственность

• canonical Property;
• canonical product / room model;
• связь property с географией, классификаторами и характеристиками;
• доступ к устойчивому контенту и поисковым атрибутам;
• canonical read model для дальнейших сервисов.

Что не должно жить внутри

• final commercial pricing;
• booking transactional states;
• supplier retries and ingestion orchestration;
• quote validity logic;
• tour composition lifecycle.

Почему этот сервис нужен отдельно

Inventory — это не только content storage. Это стабильный доменный слой, на который опираются:

• search;
• offer generation;
• Tour Builder;
• clients;
• partner surfaces;
• governance.

Он должен мыслиться как canonical inventory backbone, а не как supplier mirror.

2. Offer Service

Один из центральных контуров всей платформы.

Основная ответственность

• формирование Offer как канонической operational единицы;
• сбор supplier product, dates, occupancy, room semantics, cancellation terms и валидности;
• связь между inventory, supplier state и ценовыми данными;
• quote-ready structure;
• revalidation triggers;
• freshness and validity decisions.

Что должно входить в offer model

• property reference;
• supplier reference;
• supplier product reference;
• stay interval;
• occupancy;
• meal plan / cancellation semantics;
• availability snapshot reference;
• price snapshot reference;
• validity window;
• revalidation state;
• commercial eligibility.

Почему этот сервис ключевой

Сервисная модель платформы должна быть offer-centric. Пока этого нет, остальные сервисы будут продолжать думать hotel-centric категориями и смешивать stable и volatile data.

3. Pricing, Quote And Commercial Service

Этот контур не должен быть “калькулятором наценки поверх hotel price”. Он должен быть сервисным выражением самостоятельного commercial domain, а не техническим helper-слоем около поиска.

Основная ответственность

• разнесение raw supplier price и canonical commercial semantics;
• расчёт normalized base price;
• применение pricing rules;
• применение agency / partner-specific overrides;
• работа с валютной конвертацией;
• расчёт финального quoted price;
• фиксация Quote для конкретного actor / tenant / workspace / channel context;
• управление validity window, repricing и quote invalidation;
• объяснимость компонентов цены;
• подготовка settlement-relevant figures и событий.

Внутренние уровни цены

Сервис должен различать как минимум:

1. supplier raw price
2. normalized base price
3. commercial rule output
4. quoted price
5. settlement-relevant price view

Что Этот Контур Должен Делать Помимо Арифметики

• определять channel-aware commercial policy;
• различать indicative, quoted, booking-time confirmed и settlement-relevant monetary states;
• фиксировать, какие commercial rules были применены;
• различать visibility rules для internal, agency, partner и B2C surfaces;
• выдавать не только сумму, но и основание цены;
• участвовать в blocked publication, если commercial state противоречив или неполон.

Что нельзя смешивать

• supplier technical price;
• UI-displayed price;
• partner-specific contract price;
• booking-time confirmed price;
• finance / settlement figures.

Почему нужен отдельный сервисный контур

Commercial domain — самостоятельная проблема платформы. Без этого сервисного слоя цена будет смешана с поиском, booking и интерфейсами, а это создаст дорогое перепроектирование.

Дополнительно этот контур нужен потому, что именно здесь должны рождаться:

• Quote как коммерческая фиксация, а не побочный результат поиска;
• actor-aware price views;
• partner / agency-specific commercial semantics;
• settlement-prepared monetary outcomes;
• правила repricing и quote invalidation.

4. Booking Service

Booking Service — это не CRUD по бронированиям и не “просто вызов Supplier API”.

Основная ответственность

• переход от подтверждённого offer/quote к booking attempt;
• supplier-side reservation / confirmation flows;
• хранение booking lifecycle;
• обработка uncertain states;
• rollback / compensation;
• audit trail критических шагов;
• cancellation / amendment / recovery scenarios.

Что Booking Service Не Должен Делать Самостоятельно

• самостоятельно определять commercial policy;
• сам придумывать финальную цену вне Quote;
• хранить ad hoc channel-specific price interpretation;
• смешивать supplier booking response с settlement semantics.

Базовые доменные состояния

Минимально сервис должен уметь мыслить состояниями:

• draft
• revalidation-required
• reservation-pending
• supplier-confirmed
• platform-confirmed
• partially-failed
• cancel-pending
• cancelled
• unknown-external-state

Ключевой принцип

Booking Service должен быть stateful и failure-aware. Он не может опираться только на happy-path pipeline.

5. Post-Booking Lifecycle Service

Этот контур не должен считаться “support tail” у Booking Service.

Основная ответственность

• cancellation and amendment cases;
• supplier-driven disruption handling;
• support/dispute workflows;
• post-booking operational decisions;
• communication trace;
• handoff to settlement and clearing consequences.

6. Tour Builder Service

Tour Builder не должен быть вторичным appendage-сервисом, которому “дают поиск и цену”.

Основная ответственность

• управление TourDraft;
• композиция нескольких компонент продукта;
• правила совместимости;
• расчёт состава предложения;
• версионирование draft/proposal;
• экспорт и presentation model;
• переход к TourProposal.

Что обязательно нужно поддерживать

• ownership model;
• draft lifecycle;
• proposal lifecycle;
• historical versions;
• drift handling при изменении offer / pricing;
• возможность перепостроения тура;
• связь тура с последующими bookings.

Почему это критично

Если Tour Builder является differentiator платформы, он должен иметь собственную сервисную зрелость, а не жить как thin layer над SearchService и PricingService.

7. Identity And Access Service

Этот сервисный контур нужен потому, что платформа многосубъектна.

Основная ответственность

• пользователи;
• агентства;
• партнёры;
• роли;
• permissions;
• API clients;
• quotas;
• tenant boundaries;
• auth context;
• audit subject model.

Почему его нельзя размазывать по другим сервисам

Если identity and tenancy model распылена:

• search начинает сам решать видимость;
• pricing сам решает, чья комиссия применяется;
• booking сам хранит неустойчивые интерпретации субъектов;
• partner API начинает жить на ad hoc security model.

Для промышленной платформы так нельзя.

8. Partner Finance And Clearing Service

Этот контур отвечает не за расчёт цены, а за distribution-side financial admissibility.

Основная ответственность

• partner financial accounts;
• holds and commitments;
• deposit and credit controls;
• netting logic;
• sales blocking due to financial exposure;
• clearing entries and account state.

9. Tenant Enablement And Policy Service

Основная ответственность

• tenant policy profiles;
• supplier allow/deny logic;
• channel enablement;
• quota and capability envelopes;
• pricing and publication policy attachment;
• controlled onboarding and activation states.

10. Usage Governance Service

Основная ответственность

• metering of searches, quotes, bookings and supplier pressure;
• look-to-book style ratios;
• quota state;
• abusive usage detection;
• degrade / restrict / review outcomes.

11. Offer Integrity And Publication Control Service

Основная ответственность

• integrity thresholds;
• publication states;
• anomaly-based suppression;
• quoteability and publishability gating;
• tenant- and surface-aware publication decisions.

12. Governance And Review Service

Один из самых недооценённых, но обязательных контуров.

Основная ответственность

• provenance and lineage;
• duplicate review;
• merge adjudication;
• anomaly queues;
• confidence review;
• manual moderation;
• policy decisions по source precedence;
• operational data quality workflows.

Почему это должен быть отдельный сервисный контур

Именно этот слой превращает платформу из “умного ingestion pipeline” в управляемую operational систему, которая может работать при конфликтных данных, шумных поставщиках и спорных совпадениях.

13. Operational Control Service

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

Основная ответственность

• incident-oriented operational actions;
• replay / retry orchestration;
• stuck process handling;
• booking exception queues;
• partner key operations;
• background-job controls;
• diagnostics for long-running or partially completed workflows.

Почему он нужен

Большая платформа не может существовать только на фоне “мониторинг покажет, что что-то сломалось”. Нужны сервисные способности для ручного вмешательства и безопасного operational control.

Сервисы, Которые Не Нужно Считать Центральными На Этом Этапе

Ниже — не запрет на будущие сервисы, а важное ограничение против premature complexity.

Пока не нужно считать центральными:

• отдельный “PDF service” как автономный корневой домен;
• отдельный “notifications service” как смысловой центр платформы;
• отдельный “reporting service” как первичный архитектурный контур;
• отдельный “gateway service” как бизнес-сервис;
• отдельный “partner service” без оформленной partner and tenancy model.

Они могут появиться как runtime-компоненты или supporting modules, но не должны раньше времени подменять собой центральные доменные сервисы.

Взаимодействие Между Сервисными Контурами

На платформе должны существовать и synchronous, и asynchronous взаимодействия.

Синхронные взаимодействия

Синхронный путь нужен там, где требуется immediate decision:

• query against inventory;
• offer retrieval;
• pricing resolution;
• quote creation / re-quote;
• booking confirmation path;
• quote revalidation;
• tour recomposition в интерактивном сценарии.

Асинхронные взаимодействия

Асинхронный путь нужен там, где приоритетны throughput, decoupling и recoverability:

• ingestion updates;
• cache invalidation;
• anomaly events;
• governance review tasks;
• background repricing;
• settlement event generation;
• operational replay jobs;
• reporting/event fan-out.

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

Критический синхронный business path не должен маскироваться под асинхронную eventual-consistency магию там, где пользователю или оператору нужен точный state transition.

И наоборот, тяжёлые фоновые процессы не должны насильно загоняться в sync-only архитектуру.

Truth Policy В Сервисном Слое

Каждый сервисный контур должен знать, с каким типом truth он работает.

Inventory Service

Работает со стабильным canonical truth по объекту и классифицированному inventory.

Offer Service

Работает с operational truth ограниченного срока жизни.

Pricing And Commercial Service

Работает с layered price truth:

• raw;
• normalized;
• commercial;
• quoted;
• settlement-relevant.

Booking Service

Работает с transactional truth и uncertain-external-state truth.

Tour Builder Service

Работает с composed proposal truth, которая зависит от валидности входных offers и commercial state.

Governance Service

Работает с provenance truth, confidence truth и review outcome truth.

Без этого разделения сервисы будут принимать решения на основе данных, смысл которых они не контролируют.

Поисковый И Quote Путь Платформы

Сервисный слой должен проектироваться вокруг правильной цепочки:

Inventory
  → Offer discovery
  → Pricing resolution
  → Quote formation
  → Revalidation
  → Booking decision

Что Здесь Должно Быть Добавлено В Промышленной Модели

Промышленная модель должна мыслить эту цепочку так:

Inventory
  → Offer discovery
  → Commercial interpretation
  → Quote fixation
  → Revalidation / Repricing decision
  → Booking commitment
  → Settlement-relevant event generation

Это важно, потому что без Quote fixation и settlement-relevant event generation сервисный путь остаётся слишком коротким и не покрывает реальную денежную жизнь платформы.

Что это меняет по сравнению со старым подходом

Старый подход шёл так:

Search hotels → Get hotel prices → Book room

Для промышленной платформы этого недостаточно. Правильный путь должен опираться на offer-aware semantics, а не на прямую hotel-centric линейку.

Booking Path Как Особый Контур

Booking path — это не просто одна из функций платформы. Это самый чувствительный operational контур.

Для него должны быть определены

• точка входа в booking attempt;
• требования к revalidation;
• idempotency model;
• compensating actions;
• unknown-state handling;
• retry and replay boundaries;
• supplier confirmation semantics;
• platform confirmation semantics;
• audit semantics.

Что нельзя делать

Нельзя считать, что booking service — это просто:

• проверка availability;
• вызов supplier reservation;
• insert в database;
• ответ клиенту.

Это слишком слабая модель для реального промышленного ядра.

Tour Builder Как Сервисный Контур

Tour Builder не должен быть “клиентским удобством”, зависящим от случайного текущего ответа поиска.

Он должен уметь работать с

• draft state;
• proposal state;
• component compatibility;
• repricing;
• revalidation;
• history;
• export models;
• composition of multiple bookable and non-bookable components.

Практический вывод

Tour Builder Service должен проектироваться как самостоятельный доменный сервис, а не как thin application layer.

Identity, Commercial And Governance Как Cross-Cutting But Real Domains

Эти контуры пересекают почти всю платформу, но это не делает их “второстепенными”.

Identity And Access

Определяет:

• кто видит данные;
• кто может действовать;
• от чьего имени происходят операции;
• как работают partner clients и agency users.

Commercial Rules

Определяют:

• какую цену видит субъект;
• на каком уровне применяется override;
• какие условия считаются partner-specific или agency-specific;
• где рождается Quote;
• как появляются settlement-relevant события;
• какие commercial states допустимы к публикации на разных surfaces.

Governance

Определяет:

• как доверять данным;
• как разрешать конфликтные значения;
• как проводить ручной review;
• как объяснять происхождение решений.

Если эти три домена не закрепить сервисно, платформа будет постоянно размываться.

Пример Правильного Укрупнённого Сервисного Ландшафта

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

Supplier Ingestion
  → Governance / Matching / Provenance
  → Inventory
  → Offer
  → Pricing / Quote / Commercial
  → Booking
  → Tour Builder
  → External / Internal Surfaces

Parallel supporting contours:
  → Identity And Access
  → Operational Control
  → Observability / Audit / Reporting

Что Commercial Model Требует От Сервисной Карты

После фиксации Commercial Model — Коммерческая модель, цена, settlement и канальные условия сервисная карта платформы должна явно признавать следующие требования.

Quote Должен Быть Сервисным Артефактом, А Не UI-Проекцией

Quote должен рождаться внутри Pricing, Quote And Commercial Service как управляемая коммерческая фиксация.

Это означает, что:

• поиск и offer retrieval не должны выдавать себя за quote path;
• клиентские поверхности не должны собирать quote самостоятельно;
• booking service должен получать ссылку на подтверждённый quote context, а не вычислять цену заново по памяти.

Commercial Policy Должна Быть Channel-Aware

Один и тот же offer не обязан иметь одну и ту же commercial interpretation для:

• internal operators;
• agency users;
• partner APIs;
• B2C surfaces.

Значит, сервисная карта должна предусматривать policy-aware commercial resolution, а не единый price calculator “для всех”.

Settlement Не Должен Быть Скрыт Внутри Booking

Booking и settlement связаны, но не тождественны.

Booking Service должен управлять transactional state, а commercial контур должен:

• порождать settlement-relevant monetary figures;
• публиковать settlement-relevant события;
• поддерживать explainability денежной структуры;
• не допускать потери связи между quoted promise и downstream economics.

Commercial Publication Должна Подчиняться Governance

Если commercial state противоречив, неполон или не прошёл нужный review, сервисная карта должна поддерживать blocked publication.

Это связывает между собой:

• Pricing, Quote And Commercial Service;
• Governance And Review Service;
• Clients Layer;
• API Contracts.

Agency И Partner Не Должны Сливаться В Один Commercial Flow

Service decomposition должна оставлять место для разных commercial responsibilities:

• agency quote and proposal logic;
• partner contract-safe price exposure;
• internal override and exception handling;
• B2C presentation-safe pricing.

Если это различие не отражено сервисно, платформа вернётся к слишком грубой модели “одна цена на всех”.

Что Должно Быть Перепроверено После Этого Документа

После усиления сервисной карты должны быть последовательно перепроверены:

• Offer Pricing Booking Semantics — Семантика предложения, цены и бронирования
• Database Schema — Каноническая модель хранения платформы
• Storage Layer — Модель хранения и жизненный цикл данных
• API Contracts — Surface Contracts и правила внешнего взаимодействия
• Clients Layer — Клиентские поверхности и рабочие модели

Именно в них service responsibilities должны окончательно перейти в contract, persistence, storage и surface semantics.

Runtime Форма И Степень Разделения

На текущем этапе нельзя жёстко утверждать, что каждый доменный контур обязан сразу стать отдельным deployable microservice.

Возможны варианты:

• несколько контуров могут стартовать как modular monolith blocks;
• часть может быть вынесена в отдельные сервисы позже;
• часть supporting capabilities может жить в shared runtime until scale requires split.

Что важно

Важно не количество процессов, а правильность логических границ.

Сначала:

• правильно разделить домены;
• зафиксировать responsibilities;
• зафиксировать lifecycle and truth policy.

Потом:

• решать, где нужен отдельный runtime boundary;
• где нужен async eventing;
• где нужен strong transactional consistency;
• где нужен eventual consistency.

Что Должно Быть Перепроверено В Других Документах После Этого

После стабилизации этой сервисной модели потребуется перепроверить и скорректировать:

• Database Schema — PostgreSQL Design Сейчас схема ещё слишком property-centric и недостаточно offer-centric.

• API Contracts — OpenAPI 3.0 Specifications Сейчас API может быть слишком рано стабилизирован без окончательной service semantics.

• Clients Layer — Слой клиентов Нужно будет развести agency, partner и client-facing surfaces.

• Storage Layer — Слой хранения данных Потребуется более чёткое разведение stable, volatile, quote and booking state.

• Operations / Deployment Нужно будет читать как target runtime model после уточнения сервисных контуров.

Роль Старых Черновиков

Предыдущая версия этого документа сохранена в:

• business-services-old-2026-04-23.md

Её не следует считать актуальной service truth. Но она может оставаться полезной как архив старых идей, промежуточной конкретики и источника отдельных технических зацепок.

Текущий Практический Вывод

На текущем этапе платформа должна мыслить сервисный слой так:

• не через “4 красивых сервиса”;
• не через “один API для всех”;
• не через hotel-centric path;
• не через раннюю фиксацию портов, gRPC-методов и runtime-инфраструктуры;
• а через зрелую доменную декомпозицию platform core.

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

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

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

Новые сервисные контуры (Фаза 4)

Сервисный контур	Каноничный документ	Главные responsibilities
Payment Service	payment-domain.md	PaymentIntent lifecycle, PSP integration, refund, chargeback, settlement, payout batches
API as Product Service	api-as-product.md	partner lifecycle (sandbox → certification → production), tier model, deprecation policy, partner certification
Search & Discovery Service	search-and-discovery.md	SearchProjection, RankingPolicy, faceting, geo-search
Notification Service	notification-and-communication.md	multichannel delivery (email/SMS/push/in-app/webhook), consent management
Media & Content Service	media-and-content.md	MediaAsset, ContentBundle, ContentTranslation, image transforms
i18n Service	internationalization-and-localization.md	SupportedLanguage, SupportedCurrency, FxRateSnapshot, translation strings
Data Platform Service	data-platform-and-events-tracking.md	events tracking pipeline, DWH ingest, event store baseline
ML Platform Service	ml-platform.md	feature store, model registry, model serving, model monitoring
A/B Testing Service	ab-testing-platform.md	experiment lifecycle, cohort assignment, exposure tracking, feature flags
Analytics & BI Service	analytics-and-bi.md	partner-facing analytics dashboards, k-anonymization, tenant-scoped reports
Compliance Service	compliance-and-legal.md	DSR API, consent log, privacy review, breach notification
Economic Model Service	economic-model.md	revenue/cost tracking, unit-economics, dynamic pricing formula, billing

Новые операционные контуры (Фаза 5)

Контур	Каноничный документ	Назначение
Booking State Machine	booking-state-machine.md	14 каноничных состояний Booking, transitions, audit trail, unknown_external_state recovery
Tour Builder Operational	tour-builder-operational-model.md	CompositionRule engine, TourBookingTransaction saga, drift detection, compensation
Multi-Tenant Isolation	multi-tenant-isolation-strength.md	3 уровня изоляции (logical / dedicated_compute / dedicated_infrastructure), IsolationBoundaryCheck

Новые операционные сервисы (Фаза 6)

Сервис	Каноничный документ	Назначение
Runbooks Engine	runbooks-incident-playbooks.md	8 incident classes, runbook automation, post-mortem workflow
SLA & On-call Service	sla-and-on-call-model.md	10 SLI metrics, 4 tier SLA, on-call rotation (5 levels), service credits
DR & Capacity Service	disaster-recovery-and-capacity.md	4 recovery tiers, DR drills, capacity forecasting

Security и Audit (Фаза 10)

Сервис	Каноничный документ	Назначение
Security Service	security-architecture.md	IAM (RBAC + ABAC), encryption (at-rest + in-transit), secret lifecycle, supply chain, audit log

Главные принципы новой декомпозиции

1. Tour Builder Operational ≠ Tour Builder Domain. Domain (TourDraft, TourProposal entities) — в tour-builder-domain.md. Operational (saga, compensation, drift) — в tour-builder-operational-model.md. Две разные ответственности — два разных сервисных слоя.

2. Payment Service — отдельный bounded context. Не часть Booking Service. PaymentIntent имеет независимый lifecycle. Связь — через payment_intent_id reference в Booking.

3. ML Platform не зависит от operational services. ML Platform — sidecar для всех остальных сервисов; consumers ML predictions — search, recommendation, dynamic pricing, anomaly detection.

4. Compliance Service — cross-cutting concern. Не отдельный domain в линейке доменов; интегрируется со всеми сервисами через privacy review hooks, DSR API endpoints, audit logging.

5. Security Service — cross-cutting concern. То же самое: pervasive across all services через IAM checks, audit log emission, encryption hooks.

Связь с правилом 00000 и tier-моделью

Согласно правилу 00000 + api-as-product.md:

• сервисы Vitiana задают каноничную модель; поставщики обслуживаются через Adapter pattern (Stuba adapter, HomeToGo adapter, и т.д.) внутри Ingestion Service, не как отдельные сервисы;
• API tier определяет service capabilities доступные partner: Free/Starter/Professional/Enterprise → разные subset сервисов через capability set;
• сервисы дифференцированы по DR tier (Tier 1 для Payment/Booking; Tier 2 для Offer/Search; Tier 3 для Analytics/ML).

Связь с deployment shape

operations/deployment.md (Фаза 7) определяет 6 execution contours. Сервисная карта этого документа не дублирует execution contours — это разные оси:

• Business Services (этот документ) — что делает каждый сервис, какие domain ответственности;
• Execution Contours (deployment.md) — как сервисы группируются для runtime / deployment.

Один Business Service может попасть в несколько execution contours (например, Booking Service касается Core Transactional + Surface Delivery contours).

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

Сервисная декомпозиция расширяется с 14 базовых вопросов до полной карты 30+ сервисных контуров (4 центральных core + 12 платформенных + 3 операционных + 1 security). Каждый — со своим каноничным документом-источником истины.

При проектировании конкретного сервиса использовать этот документ как сервисную карту, специализированный домен — как source of truth для бизнес-логики, deployment.md — для runtime/deployment shape.

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