Comments 8
return new Response();
В приведенном примере, скорее всего, начальная реализация OrderService подразумевала не просто пустой ответ, а результат работы сервиса (order_id, notification_result, shipped_result).
С переходом на асинхронные сообщения, мы также переходим и на асинхронные ответы. В случае когда формат ответа нужно сохранить, мы должны будем не переписывать старый контроллер, а добавить новый. После чего нужно ждать когда все кто использовал этот контроллер перейдут на новую асинхронную версию.
И как быть, если наши партнеры не особо то и хотят этим заниматься? Их все устраивало раньше, они отправляли запрос и получали ответ, а теперь им надо городить какие то сокеты, пинги, лонгпулинг или что то еще.
Реклама в рекламе... Чем плох стандартный https://symfony.com/doc/current/components/messenger.html в сравнении с?
Ничем не плох, это такой же инструмент. Какой выбрать решать вам. Статья ведь не про SymfonyMessenger. Тег стоит Laravel, с чего вдруг symfony стал стандартным? Можно ведь ваш комментарий перефразировать для Prooph или Tactician. А представьте каждый напишет комментарий с ссылкой на свой CommanBus инструмент?
Конечно, я прошел посмотреть прежде чем написать вопрос. Саги видел. От переводчика детали не ожидаются, но было бы неплохо от @FanatPHPраз рекомендовал.
Меня напрягает в событиях сложность их отслеживания. Когда событий становится много и одно событие может публиковаться из разных мест и обрабатываться разными получателями, то становится сложно понять когда и почему что-то происходит.
Без схемы никак
Согласен с Вами, моё личное мнение, что весь важный бизнес код должен быть внутри useCase'а , поэтому письмо еще можно вынести в события, но передачу в службу доставки - нет. Иначе получится лазанья код из разбросанной по приложению важной логики, которую устанешь собирать. Составление карты "этого", вместо того чтобы так не делать, больше похоже на способ создать себе сложности, а потом героически их преодолевать.
Проектируем реактивное — Message-Driven системы на PHP