Observer - реакція на події

Observer організовує реакції на події без жорстких зв'язків: об'єкт сповіщає підписників про зміну, не знаючи, хто вони.

Яку проблему вирішує

Коли на одну дію (оплата замовлення) треба навісити кілька побічних реакцій (лист, вебхук, аналітика), вшивання їх прямо в код дії робить його громіздким і прив'язаним до конкретних реакцій. Додати нову - означає правити вихідну логіку.

Як вирішує

Об'єкт лише публікує подію про факт. Слухачі підписуються на неї й виконують побічні дії незалежно. Нову реакцію додаєш новим слухачем, не торкаючись джерела події. У Laravel це Events, Listeners і Subscribers.

class OrderPaid
{
  public function __construct(public Order $order) {}
}

class SendReceipt
{
  // У Laravel 11+ слухач автоматично знаходиться за типом аргументу handle().
  public function handle(OrderPaid $event): void
  {
    Mail::to($event->order->email)->send(new ReceiptMail($event->order));
  }
}

// Диспатч події (хелпер event() або статичний метод OrderPaid::dispatch()):
event(new OrderPaid($order));

// Явна реєстрація, якщо авто-discovery вимкнено:
Event::listen(OrderPaid::class, SendReceipt::class);

// У тестах події легко фейкати:
Event::fake();
event(new OrderPaid($order));
Event::assertDispatched(OrderPaid::class);

Де застосовувати

• Логування, нотифікації, вебхуки, аналітика - усе, що є реакцією на доменний факт.
• Коли реакцій багато і вони можуть з'являтися чи зникати незалежно.

Плюси та мінуси

• + Нові реакції додаються без змін у вихідній логіці; контролер лишається тонким.
• + Події легко фейкати в тестах і перевіряти їх відправку.
• − Прихований потік керування: за подією важко простежити, що саме виконається.
• − Важких слухачів треба відправляти у чергу, інакше вони сповільнять основний запит.