ddadminandClaude Fable 5
6f18e9989c
- Зачем:
- спека разрослась до 1058 строк, а журнал решений в разделе 9 читался
только целиком; агентам и людям нужен дешевый адресный заход к
основаниям решений генератора.
- Что:
- заведены ADR 0015 (пояс счетчика), 0016 (паспорт куки) и 0017 (номер
заказа); четыре адресные ссылки на «раздел 9» перешиты на них.
- раздел 9 пересобран в 11 тематических подразделов с датами и тикетами
у каждого решения и закрыт пометкой о заморозке; устаревшие
промежуточные замеры свернуты до указателей на актуальные.
- строка статуса в шапке отмечает закрытие спеки как документа этапа 2.
- Проверка:
- wc -l docs/specs/2026-08-01-generator.md (951, было 1058);
rg -n 'раздел[а-яё]* 9|разделы 8 и 9' docs -g '*.md' — 18 попаданий,
все классифицированы; разделы 1-8 нетронуты (сверка хешем).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
35 lines
2.1 KiB
Markdown
35 lines
2.1 KiB
Markdown
# ADR 0017. Номер заказа объединяет две проекции покупки
|
|
|
|
Дата: 28 августа 2026 года. Статус: принято. Реализация — тикет #40.
|
|
|
|
## Решение
|
|
|
|
Номер заказа включает день по модельному времени и порядковый номер покупки в
|
|
этот день, например `20260603-0042`. Событийная сторона пишет его в
|
|
`purchaseID`, бэкенд — в `order_id`; обе стороны берут один номер из плана
|
|
покупки.
|
|
|
|
Все покупки, попавшие в поток дня, нумеруются в порядке событий и до любых
|
|
потерь следующих этапов.
|
|
|
|
## Почему
|
|
|
|
По читаемому номеру сразу виден день заказа. Один номер соединяет две проекции
|
|
одной покупки. Генераторы кликстрима и бэкенда не согласуют его отдельно.
|
|
|
|
Присвоение до потерь сохраняет номера остальных заказов: исчезновение одного
|
|
события не должно перенумеровывать чужие покупки и разрывать связь с бэкендом.
|
|
|
|
## Отклонено
|
|
|
|
- Присваивать номера после внесения потерь: одна потеря сдвинула бы все
|
|
следующие номера за день и разорвала бы связь уже созданных проекций.
|
|
|
|
## Следствия
|
|
|
|
`purchaseID` и `order_id` изначально совпадают. Из-за расхождения событие может
|
|
исчезнуть после присвоения номера, но номера сохранившихся заказов не меняются.
|
|
|
|
Решение принято при исполнении тикета #40 и зафиксировано в спеке этапа 2,
|
|
раздел 9.
|