Size: a a a

Software Design/Architecture/Zen

2021 June 07

ST

Serguei Tarassov in Software Design/Architecture/Zen
на уровне домена тебе нужно просто собрать дерево из объектов, как оно будет храниться - инвариантно, просто через маппинг. Как представлять деревья в домене - это та же тема, что и деревья из учебника Кнута
источник

А

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

IK

Ivan Katkov in Software Design/Architecture/Zen
Человек оформляет заказ, после чего уже идёт процесс оплаты итд. Как только заказ сформирован, человек уже воспользовался скидкой, разве нет?
источник

А

Антон in Software Design/Architecture/Zen
Нет, менеджеры так не хотят. Не оплатил – не воспользовался.
источник

SB

Sergei Baikin in Software Design/Architecture/Zen
Сага как раз про long living process. Как раз ваш случай имхо
источник

А

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

SB

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

А

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

А

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

SB

Sergei Baikin in Software Design/Architecture/Zen
Через какое-то время после того как пользователь нажал оплатить
источник

SB

Sergei Baikin in Software Design/Architecture/Zen
Спросить у менеджеров сколько ждать хотим. На сколько лочить.
источник

А

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

SB

Sergei Baikin in Software Design/Architecture/Zen
Почему кролик ненадежный?

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

SB

Sergei Baikin in Software Design/Architecture/Zen
Какая разница кто будет ходить. Задача инфраструктуры чтобы сага получала сообщение. Каким образом это дело десятое.
источник

А

Антон in Software Design/Architecture/Zen
Не кролик ненадежный, а подход. Но я не уверен, надо попробовать. Много факторов, где можем отвалиться, и это настораживает.
источник

А

Антон in Software Design/Architecture/Zen
В данном случае это дело первое. Это и было предметом вопроса.
источник

SB

Sergei Baikin in Software Design/Architecture/Zen
Возьмите готовое решение. И вопрос отпадёт.
Dapr.io например
источник

SB

Sergei Baikin in Software Design/Architecture/Zen
Ну или что то специфическое для вашего языка
источник

А

Антон in Software Design/Architecture/Zen
Смотрел. Пойду еще раз гляну. Спасибо за участие.
источник

˸A

˸̧̨ ͅBlack Akula˸̧̨ ... in Software Design/Architecture/Zen
Представьте, что купоны находятся не в вашей системе. Система купонов позволяет либо закрыть сессию с чарджем этого купона, либо продолжать сессию без блокировки купона. Ваши действия?

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