ddadminandClaude Fable 5
7972847601
- Зачем: - развилка #130 карты #127: заказу нужен объект в DDS — зерно, состав, движок и судьба служебных колонок; резолюции этапа 4 нужен дом в git. - Что: - создан набор docs/architecture/dds/ по ADR 0011: README с картой модели и правилами слоя, order.md с моделью заказа — зерно «заказ в текущем состоянии», позиции массивами, MergeTree с заменой партиций, свои _load_id/_load_ts вместо ярлыков ODS (закрывает наследство #85); - указатели на модель добавлены в orders/README.md, orders/ingestion.md и storage.md. - Проверка: - только документы; относительные ссылки сверены с деревом docs/. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Слой DDS: бизнес-модель хранилища
Устройство детального слоя: сущности, которыми хранилище говорит с витринами, их связи и правила слоя. Набор собирается развилками карты #127 (этап 4) и правится по мере постройки.
Рамки заданы мастер-спекой «Боевой реализм стенда (v2)»: карта таблиц и витрины — раздел 7, сверка — раздел 4, склейка идентичностей — раздел 5. Дом выбран на первой развилке карты: резолюции этапа 4 живут здесь, по хранилищную сторону границы «источник | хранилище». Устройство источников остаётся их собственным наборам (заказы бэкенда) — генератор переносим и о нашем DDS не знает.
Карта модели
Целостность модели — связи и ко-локация — живёт в этом разделе; файлы сущностей держат глубину и на карту ссылаются.
- Заказ (
dds.order) — физическая сущность: одна строка — заказ в текущем состоянии, позиции массивами в строке, наполняется заменой партиций — модель заказа. - Сессия (
dds.session) — зерно и правила сборки решает развилка #131. - Событие (
dds.event_v) — контракт над ODS, а не копия: язык бизнес-модели событию даёт развилка #132. - Карта идентичностей (
dds.identity_map) — кука ↔ пользователь магазина; сборку решает развилка #133.
Связи держатся двумя ключами моста (спека, разделы 4 и 5): purchaseID[1]
события равен order_id заказа — по нему идут сверка и сборка склейки;
user_id заказа связывает куки одного человека. Ко-локацию задаёт
шардирование: события и карта идентичностей раскладываются одним выражением
от куки, заказы — от order_id. Поэтому обогащение витрин склейкой
локально, а сверка и сборка карты ходят через GLOBAL JOIN с обеими
сторонами-подзапросами (исследование
соединений).
Правила слоя
- DDS обслуживает человека с дашбордом: время лежит в поясе счётчика, пересчёт — один раз при наполнении слоя (дока хранилища, «Часовые пояса»).
- Служебные колонки — координаты собственной загрузки слоя; чужие ярлыки не переносятся, а спрашиваются у их слоя по ключу сущности. Вывод правила и цепочка расследования — модель заказа.
Открытые решения
- Сессии, контракт
dds.event_v, сборкаdds.identity_map— развилки #131–#133 карты #127. - Запуск трансформаций и механика замены партиций на кластере — #134 и этап 5.
- Витрины DM — #135.
Родословная
Дом набора и первая сущность собраны развилкой #130 карты #127; форма набора — ADR 0011.