могут попадать в асинхронные очереди и есть какие-то инварианты в доменах. Допустим при заказе трансорта вес товара не может бьть больше 1тонны для некоторых типов транспорта. Каким образом пользователю при заказе сообщить о том, что оформить подобный заказ невозможно? Думал над несколькими вариантами:
1. Проверка перед отправкой команды. Несильно нравиться, потому что в домене и так есть эта проверка, это бизнес правило, надо дублировать проверку.
2. Кинуть исключение. Неплохой вараинт если синхронная обработка, но что если асинзронная... Как сообщать пользователю, что команда отклонена?
3. Кинуть евент, что очень похоже на исключение
Что посоветуете по валидации команд и главное оповещанию юзеру об ощибке?
Все зависит от бизнесовой важности операции и среднего времени ее асинхронной обработки. Если действие важно, а обработка занимает секунды, но вполне допустимо кинуть пользователя на страницу с ожиданием (спиннер загрузки). Такое например часто можно видеть в момент онлайн оплаты картой. Эта страница держится в фокусе юзера десяток секунд, регулярно проверяя статус готовности асинхронной операции. Если есть затык в очереди и не удалось дождаться - то выводится что-то типа "Проверьте готовность через N времени в личном кабинете". Таким образом у вас получится синхронный UX при асинхронной обработке. Если же это не нужно и не важно, то просто покажите юзеру статус "Заказ в обработке", а при готовности уведомите его любым подходящим способом: нотификейшн на сайте, пуш, емейл, смс.
1 имхо. Дублирование можно тегами победить или общими правилами которые работют и подгружаются и там и там
вынести проверку в апп-сервисе под капотом у которого доменный сервис и дергать его перед отправкой?
Что за теги?
#bussness_rule_1
В каком месте дергать? После того как команда попала в очередь асинхронную?
перед тем как поместить в очередь
че-то я по ходу сильно тупой...)
ты не один 🙁 Я тоже не понимаю
Обычные теги по которым можно найти все места на которые надо обратить внимание при изменнии кода
Обсуждают сегодня