/url_a1/url_b2/url_c1/url_d2 - это ликвидно

/url_a1/url_c1/url_d2//url_b2 - а это нет

шотенадо

онямешник

ну

event sourcing

CQRS + DDD

тогда не парься кидать в евенте еще 2 евента не нужно

лучше сделай: UserWasRegisterEvent => [ SendEmailListentrs::class, AnotherLister:class }

почему ?

у тебя уведомлениями и email занимаются джобы

в слушателях ты просто вызываешь их когда нужно(отработало событие)

прокидывай тип внутрь

будет так: NewUserREgister::class => [ SendMailListeners::class] //SendMailListeners handle() { try{ EmailJob::dispatch($email,$type); }

да

ты для этого маппишь чо тебе надо на паблик проперти

что бы в слушателе сделать $event->public

тут смотря что тебе нужно

ты можешь сам задать обсерверы

можешь сам задать $dispatchedEvents

можешь сам слушать eloquent events

которые она кидает

неее

я же тебе говорю прокидывай в слушателя

тип

и пользователя

инстанцируй задачу и отдавай ей

будет так: NewUserREgister::class => [ SendMailListeners::class] //SendMailListeners handle() { try{ EmailJob::dispatch($email,$type); }

у тебя у события newUserREgister

будет $user

тип ты определяешь сам внутри контекста

у тебя один евент

один слушатель

неважно какой тип

NewUserRegister => SendMailListerners::class NotificationListeners::class

без диспатча

просто NewUserREgister

event(new UpdateWasReceived($update));

да

всм юзается

они работают с пропертями события

тобишь просто ref_count увеличивается в zval

Event::dispatch(new NewUserRegister(new Data($data)) //жобы EmailJob::dispatch($data->email,$data->type) NotificatioN::dispatch($data->user,$data->another

я понял тебя

загоняешься по хуйне

ты просто не правильно юзаешь события

о чем и свидетельствует дохуя пропертей

в конструкторе

тебе не нужна стратегия для событий

ок перефразирую

тебе не нужна стратегия в евенте

в котором ты отправляешь нотифы

там тупой пример недописанный бот

я не стал аплоадить с битбакета

там дохуя ветка вперед ушла

посмотри видосики в тытрубе

10 минут с докой и все

Да.

флоу отправка сообщения всем пользователям. кинул евент $users = User::all(); event(new Notification($users); замаппил на паблик свойство в слушателе: foreach($event->users as $user) SendMessageJob::dispatch($user,'hello'); }

заодно научишься в супервизор

Профит, например, при отправке мейлов.

потому что у телеги есть рейт лимиты

не более 30 сообщений в секунду

потому ты и диспатчишь джобы с таймаутом

а в супервизоре выставляешь сколько воркеров сколько нужно

что бы не нарушить лимиты

не нужен

Суть даже не в этом. Обычно обработкой джобов занимается отдельно поднятый демон. И чтобы юзер, например, при регистрации не втыкал в обновление страницы, ему говорят, что его рега обрабатывается, а мыло прибудет потом. Демон пока прокручиват джобы и шлёт эти самые письма. Просто отправка мыла может быть довольно длительным процессом. Хотя это не единственный профит от джобов, но самый наглядный.

Эм, пожалуй да :D

суть в отложенных вычислениях

ну читал как справочник когда нужно было на работе

мы пилили CQRS + DDD

с ларой в ддд не лезь

мы пилили CQRS + DDD

охуенно

круто тебе

клизмами

Использовать long polling

охуенно

по итогу я убрал DDD из резюмехи. Один раз на собесе попался тип, который прочитал Эванса страниц 150 и начал мне рассказывать, что все неправильно, а как правильно не знает. Решил избавиться от таких диалогов на собесе, енивей никто не знает как правильно, все свои велосипеды архитектурные делают

а ты собсно че пришел-то? ищешь как себе кишку расширить?

дропайте дауна, очевидно оно пытается рофлить