SB
созранение и запуск процесса я бы сделал 2 отдельными действиями
Size: a a a
2021 July 28
SB
Большинсво данных формы обычно не нужны в аггрегате
SB
так и в чем тоогда проблема разбития оного на независимые процессы?
Прсто в конце должне быть отдельный процесс который проверяет что все другие ему отчитались об успещном успехе
Прсто в конце должне быть отдельный процесс который проверяет что все другие ему отчитались об успещном успехе
ПГ
Ну если брать мой кейс, если я сохраняю форму отдельно. Заказ подтвердился, пошел в разработку. А оформление доставки отвалилось, и клиент не стал переоформлять. Хотя тут навернео выход, чтобы заказ подтверждался после проверки адреса асинхронно, но у нас есть заивимость цены от время оформления заказа, т.е. асинхронно тоже не выйдет
ПГ
Так процессы и так независимы, и да, можно написатьотдельный процесс/сагу которая будет следить откатывать/подтверждать. Но есть ли в этом профит?
SB
Как часто отваливается?
Почему менеджеры не могут это порешать?
Почему менеджеры не могут это порешать?
М
Здравствуйте. Прошу уделить мне чуточку внимания: проголосуйте в следующем опросе за 'да' пожалуйста. Заранее благодарен.
М
Я мим?
Анонимный опрос
Проголосовало: 779ПГ
Ну на практике такого нет, так как есть еще проверка перед с помощью фронта. Но я же должен учесть и без фронта такие вещи
SB
Как доставка вас блокирует если за нее уже уплочено?
Не проще ли попросить клиента предоставить актуальные\коректные даные?
Не проще ли попросить клиента предоставить актуальные\коректные даные?
ПГ
Не уплочено, у нас оплата постфактум. Заказать в долг можно
ПГ
Ну я не про саму доставку
ПГ
я про оформления данных для доставки
SB
обычно нет смысла уситывать редкие случаи
если кто то пойдет в обход фронта то и фиг на него
если кто то пойдет в обход фронта то и фиг на него
SB
какая разница оформит он их до заказа после или во время?
ПГ
У нас одна форма. После ее сабмита идет процесс "подвтерждение заказа", который в коде включает в себя два юзкейса "сохранение доставки/данных для доставки", "подтверждение заказа". В каждом из которых есть условия и каждый из которых может отвалиться (редко или если без фронта) с выводом мессаджа клиенту.
ПГ
Т.е. просто меняя эти юзкейсы местами в коде, проблема не решается
ПГ
В бизнесе подтвержденный заказ без сохраненных данных о доставке - не имеет смысла. А также данные о доставке без заказа - тоже. Под атомарностью я подразумеваю - мне нужно или все сохранить/изменить или ничего. Возможно я неверно выражаюсь в терминах
SP
Хватит формами думать
NF
хах, ток хотел написать то же самое)