Если ты хоть раз писал жирный контроллер, который отправляет письма, дергает API и при этом ещё пишет в базу, то знаешь это чувство — хочется выйти в окно. Вот тут в Laravel и появляются Events & Listeners. Они дают возможность разнести сраный монолитный метод по кускам. Событие произошло — слушатель отработал. Всё.

Событие: просто класс с данными

Laravel тебе не продаёт магию — событие это просто класс. Например:

php artisan make:event OrderShipped

В итоге получаешь:

class OrderShipped
{
    use Dispatchable, InteractsWithSockets, SerializesModels;

    public $order;

    public function __construct($order)
    {
        $this->order = $order;
    }
}

Да, выглядит пафосно, но внутри обычный PHP-класс с полем $order.

Слушатель: та самая работа за сценой

Дальше:

php artisan make:listener SendShipmentNotification --event=OrderShipped

Получаешь:

class SendShipmentNotification implements ShouldQueue
{
    use InteractsWithQueue;

    public function handle(OrderShipped $event)
    {
        // Отправляем письмо, пинаем курьера, уведомляем маму
    }
}

Главное — вся грязь уходит сюда. А ShouldQueue значит, что код не будет тормозить юзера, а улетит в очередь. Правда, если очередь не поднята, Laravel честно завалит задачу и напишет, что ты идиот.

Регистрация: ещё один конфиг

В EventServiceProvider:

protected $listen = [
    OrderShipped::class => [
        SendShipmentNotification::class,
    ],
];

Да, это всё ручками. Если любишь магию — придётся разочароваться, Laravel не подбирает слушатели сам.

Диспатч события: один вызов

Когда заказ поехал:

event(new OrderShipped($order));

И всё, поехало по конвейеру. Код контроллера не пухнет от лишних действий, а нужные слушатели сами срабатывают.

Очереди: где всё ломается

Слушатели часто делают тяжёлую работу — типа отправки писем или запросов во внешний сервис. Поэтому их кидают в очередь. Но будь честен: если у тебя нет настроенного воркера, Redis или хотя бы database-очереди, то вся эта "асинхронность" останется в мечтах.

С ShouldQueue Laravel красиво уходит в фон. Но если очередь лежит, то твои события будут тухнуть пачками, а пользователи будут писать в саппорт: "где моё письмо?".

Когда Events & Listeners реально спасают

  • У тебя миллион побочных эффектов после одного действия (регистрация юзера = письмо, лог, метрика, пуш). Всё это можно разбросать по слушателям.
  • Ты не хочешь держать код монолитным и впихивать всё в один контроллер.
  • Нужно быстро отрубить ненужную логику — просто комментируешь слушатель, событие живёт дальше.

Когда это превращается в ад

  • У тебя сто событий, двести слушателей и никто не понимает, что за чем вызывается.
  • Половина слушателей в очереди, половина нет. В итоге часть логики работает синхронно, часть "где-то потом". И привет, ночные дебаги.
  • События размазаны так, что один баг приходится искать через три слоя костылей.

Вывод

События и слушатели в Laravel — это не серебряная пуля, а банальный способ не захламлять контроллеры и модели. Работает норм, если у тебя есть голова на плечах и хоть какая-то дисциплина в коде.

А если нет — через полгода проект превращается в "взрыв на фабрике фейерверков", где одно событие триггерит десяток слушателей, а ты сидишь и думаешь: "какой мудак это писал?" — а потом смотри на историю коммитов в гите и вспоминаешь, что это был ты.