- Зачем: - развилка #132 карты #127: витринам DM и сборке сессий нужен контракт события на языке бизнес-модели, первый пример правила «слой — это контракт, а не обязательно копия данных». - Что: - создан docs/architecture/dds/event.md: представление над ods.event_v, имена модели (event_id, event_time в поясе счётчика, event_date переименованием), расшифровка device_category, скрыты VisitID, Sign, ecommerce и служебные колонки. - в README карта модели ведёт на event.md, развилка убрана из открытых решений; session.md ссылается на резолюцию судьбы VisitID. - Проверка: - вычитка; относительные ссылки в docs/architecture/dds/ ведут на существующие файлы. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
61 lines
4.5 KiB
Markdown
61 lines
4.5 KiB
Markdown
# Слой DDS: бизнес-модель хранилища
|
|
|
|
Устройство детального слоя: сущности, которыми хранилище говорит с
|
|
витринами, их связи и правила слоя. Набор собирается развилками карты #127
|
|
(этап 4) и правится по мере постройки.
|
|
|
|
Рамки заданы мастер-спекой [«Боевой реализм стенда
|
|
(v2)»](../../specs/2026-07-30-stand-v2-realism.md): карта таблиц и витрины —
|
|
раздел 7, сверка — раздел 4, склейка идентичностей — раздел 5. Дом выбран
|
|
развилкой #130 — первой, которой понадобилось записать резолюцию в доки:
|
|
записи этапа 4 живут здесь, по хранилищную сторону границы
|
|
«источник | хранилище». Устройство источников остаётся их
|
|
собственным наборам ([заказы бэкенда](../orders/README.md)) — генератор
|
|
переносим и о нашем DDS не знает.
|
|
|
|
## Карта модели
|
|
|
|
Целостность модели — связи и ко-локация — живёт в этом разделе; файлы
|
|
сущностей держат глубину и на карту ссылаются.
|
|
|
|
- **Заказ** (`dds.order`) — физическая сущность: одна строка — заказ в
|
|
текущем состоянии, позиции массивами в строке, наполняется заменой
|
|
партиций — [модель заказа](order.md).
|
|
- **Сессия** (`dds.session`) — расчётная сущность: одна строка — визит,
|
|
нарезку по правилу визита стенд делает сам, `VisitID` генератора — эталон
|
|
сверки; наполнение заменой дневной партиции — [модель сессии](session.md).
|
|
- **Событие** (`dds.event_v`) — контракт над ODS, а не копия: представление,
|
|
переводящее событие на язык бизнес-модели, — [контракт события](event.md).
|
|
- **Карта идентичностей** (`dds.identity_map`) — кука ↔ пользователь
|
|
магазина; сборку решает развилка #133.
|
|
|
|
Связи держатся двумя ключами моста (спека, разделы 4 и 5): `purchaseID[1]`
|
|
события равен `order_id` заказа — по нему идут сверка и сборка склейки;
|
|
`user_id` заказа связывает куки одного человека. Ко-локацию задаёт
|
|
шардирование: события и карта идентичностей раскладываются одним выражением
|
|
от куки, заказы — от `order_id`. Поэтому обогащение витрин склейкой
|
|
локально, а сверка и сборка карты ходят через GLOBAL JOIN с обеими
|
|
сторонами-подзапросами ([исследование
|
|
соединений](../../research/2026-08-22-distributed-join.md)).
|
|
|
|
## Правила слоя
|
|
|
|
- DDS обслуживает человека с дашбордом: время лежит в поясе счётчика,
|
|
пересчёт — один раз при наполнении слоя ([дока хранилища](../storage.md),
|
|
«Часовые пояса»).
|
|
- Служебные колонки — координаты собственной загрузки слоя; чужие ярлыки не
|
|
переносятся, а спрашиваются у их слоя по ключу сущности. Вывод правила и
|
|
цепочка расследования — [модель заказа](order.md).
|
|
|
|
## Открытые решения
|
|
|
|
- Сборка `dds.identity_map` — развилка #133 карты #127.
|
|
- Запуск трансформаций и механика замены партиций на кластере — #134 и
|
|
этап 5.
|
|
- Витрины DM — #135.
|
|
|
|
## Родословная
|
|
|
|
Дом набора и первая сущность собраны развилкой #130 карты #127; форма
|
|
набора — [ADR 0011](../../adr/0011-component-docs.md).
|