на уровне домена тебе нужно просто собрать дерево из объектов, как оно будет храниться - инвариантно, просто через маппинг. Как представлять деревья в домене - это та же тема, что и деревья из учебника Кнута

Привет. А подскажите, есть ли какой подход/паттерн для случаев, когда у нас полная оплата заказа растянута по времени и нам надо обеспечить на это время запрет пользователю воспользоваться скидкой второй раз. В двух словах: пользователь применяет скидку и может после этого оплатить заказ (все как обычно: перешел на чекаут, оплатил, мы получили вебхук) по выгодной цене, однако он же может и не оплатить заказ (уйти с чекаута), или вебхук может доставляться дольше обычного, а на это время (неопределенное, но конечное) нам надо убедиться, что пользователь еще находится на стадии процессинга (находится на чекауте/ждем вебхук) и не разрешать воспользоваться скидкой. Но это не может длиться вечно и когда-то нам надо понять, что юзер в итоге заказ не оплатил и скидку ему можно снова разблокировать. Тут еще штука в том, что он заказ может оплатить, вебхук может прийти, но мы пойдем во внешнюю систему кое-что активировать (как раз система и предоставляет скидку), а общение с ней происходит через очередь, где обычно много сообщений, т.е. есть задержка в минуту-две. Мьютексы не подходят, проверять ордеры по времени тоже не хочется, отмечать в бд/кэше тоже не оч. Ну и саги тоже не про это. Что еще можно рассмотреть?

Человек оформляет заказ, после чего уже идёт процесс оплаты итд. Как только заказ сформирован, человек уже воспользовался скидкой, разве нет?

Нет, менеджеры так не хотят. Не оплатил – не воспользовался.

Сага как раз про long living process. Как раз ваш случай имхо

Да, но я не слышал, чтобы у саг были какие-то таймеры на этапы. Мол, 10 минут на оплату, 10 минут на ожидание вебхука. У нас-то нет никакого фейла, просто пользователь ушел с чекаута, вебхук к нам не придет. Ставить таймеры на оплату у нас тоже нельзя, у нас нет корзины, просто импульсивные покупки: выбрал – перешел на чекаут.

Сага это подход к проектированию. Не очень понятно зачем вы туда свою бизнес логику примешиваете. Как хотите так и будет. Таймеры в сагах которые я видел почти везде есть. Без таймеров половину полезности теряется имхо.
Про веб хук не понял. Началась оплата. Дальше или веб хук придёт или вы статус раньше поверите. Или вообще отмените по таймауту.

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

Нет у нас таймаута, говорю же. С платежкой интеграция только в одну сторону – они идут к нам. Можно, конечно, и самим чекать статус, но нужно определиться с точкой опоры: когда ходить в этот апи.

Через какое-то время после того как пользователь нажал оплатить

Спросить у менеджеров сколько ждать хотим. На сколько лочить.

И кто будет ходить? Крон? Откладывать сообщения в кролик, чтобы проверить через 5 (условно) минут? Ненадежный подход, имхо.

Почему кролик ненадежный?

Используйте любой надёжный бакенд. Sql базу например. Туда складывайте сообщения.

Какая разница кто будет ходить. Задача инфраструктуры чтобы сага получала сообщение. Каким образом это дело десятое.

Не кролик ненадежный, а подход. Но я не уверен, надо попробовать. Много факторов, где можем отвалиться, и это настораживает.

В данном случае это дело первое. Это и было предметом вопроса.

Возьмите готовое решение. И вопрос отпадёт.
Dapr.io например

Ну или что то специфическое для вашего языка

Смотрел. Пойду еще раз гляну. Спасибо за участие.

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

Чаще всего системы закрывают сессию, а в случаях ошибки оплаты (что должно быть редко) - кастомер-сервис разруливает вручную с клиентом (например, создают ему новый купон)