1. El debate: ¿llamada directa o evento?

Cuando ocurre algo importante en tu aplicación (un usuario se registra, se procesa un pago, se crea un pedido), tienes que decidir cómo reaccionar. Hay dos caminos:

2. Llamada directa

2.1 ¿Cómo funciona?

El código que detecta el evento llama directamente a las funciones que deben ejecutarse. Simple y explícito.

// OrderController.php
public function store(OrderRequest $request)
{
    $order = Order::create($request->validated());
 
    // Llamadas directas, en secuencia
    $this->sendConfirmationEmail($order);
    $this->notifyWarehouse($order);
    $this->updateStats($order);
 
    return response()->json($order, 201);
}
 
private function sendConfirmationEmail(Order $order): void
{
    Mail::to($order->customer->email)->send(new ConfirmationMail($order));
}
 
private function notifyWarehouse(Order $order): void
{
    WarehouseService::notify($order);
}

2.2 Ventajas

• Fácil de leer: el flujo está todo en un lugar
• Ideal para prototipos o lógica simple con 1-2 pasos
• Sin configuración adicional: no hay que crear clases extra
• El IDE puede trazar la ejecución sin ambigüedad

2.3 El problema: el controller crece

Tres meses después, el negocio pide más cosas al crear un pedido:

// El mismo método, 3 meses después...
public function store(OrderRequest $request)
{
    $order = Order::create($request->validated());
 
    $this->sendConfirmationEmail($order);   // original
    $this->notifyWarehouse($order);          // original
    $this->updateStats($order);              // original
    $this->addLoyaltyPoints($order);         // nuevo - marketing
    $this->syncWithERP($order);              // nuevo - contabilidad
    $this->alertFraudSystem($order);         // nuevo - seguridad
    $this->createShipmentLabel($order);      // nuevo - logística
 
    return response()->json($order, 201);
}

3. Eventos en Laravel

3.1 Las tres piezas

3.2 El mismo ejemplo con eventos

Paso 1 — Definir el evento

// app/Events/OrderCreated.php
class OrderCreated
{
    public function __construct(
        public readonly Order $order
    ) {}
}

Paso 2 — Los listeners (uno por responsabilidad)

// app/Listeners/SendConfirmationEmail.php
class SendConfirmationEmail
{
    public function handle(OrderCreated $event): void
    {
        Mail::to($event->order->customer->email)
            ->send(new ConfirmationMail($event->order));
    }
}
 
// app/Listeners/NotifyWarehouse.php
class NotifyWarehouse
{
    public function handle(OrderCreated $event): void
    {
        WarehouseService::notify($event->order);
    }
}
 
// app/Listeners/AddLoyaltyPoints.php — añadido después, sin tocar nada
class AddLoyaltyPoints
{
    public function handle(OrderCreated $event): void
    {
        LoyaltyService::award($event->order->customer, 100);
    }
}

Paso 3 — Registrar en el Provider

// app/Providers/EventServiceProvider.php
protected $listen = [
    OrderCreated::class => [
        SendConfirmationEmail::class,
        NotifyWarehouse::class,
        UpdateOrderStats::class,
        AddLoyaltyPoints::class,    // nuevo: solo añadir aquí
        SyncWithERP::class,         // sin tocar el controller
        AlertFraudSystem::class,
    ],
];

Paso 4 — El controller queda limpio para siempre

// app/Http/Controllers/OrderController.php
public function store(OrderRequest $request)
{
    $order = Order::create($request->validated());
 
    event(new OrderCreated($order)); // su trabajo termina aquí
 
    return response()->json($order, 201);
}
// Este método nunca necesita cambiar, sin importar cuántos listeners se añadan

4. Listeners asíncronos con ShouldQueue

Una ventaja exclusiva de los eventos: convertir cualquier listener en asíncrono es trivial.

// Solo añadir 'implements ShouldQueue'
class SendConfirmationEmail implements ShouldQueue
{
    public string $queue = 'emails';  // cola específica (opcional)
    public int $tries = 3;             // reintentos en caso de fallo
 
    public function handle(OrderCreated $event): void
    {
        // Esto se ejecuta en background, sin bloquear la respuesta HTTP
        Mail::to($event->order->customer->email)
            ->send(new ConfirmationMail($event->order));
    }
 
    public function failed(OrderCreated $event, Throwable $exception): void
    {
        // Se llama si los 3 intentos fallan
        Log::error('Email fallido para orden: ' . $event->order->id);
    }
}

5. Testing

// Tienes que mockear todos los servicios
public function test_order_creation()
{
    Mail::fake();
    $this->mock(
        WarehouseService::class,
        fn($m) => $m->shouldReceive('notify')
    );
    $this->mock(
        LoyaltyService::class,
        fn($m) => $m->shouldReceive('award')
    );
    // ...un mock por cada llamada directa
 
    $this->post('/orders', $data)
         ->assertStatus(201);
}

// Solo verificas que el evento se disparó
public function test_order_creation()
{
    Event::fake();
 
    $this->post('/orders', $data)
         ->assertStatus(201);
 
    Event::assertDispatched(OrderCreated::class);
}
 
// Cada listener tiene su propio test:
public function test_sends_email()
{
    Mail::fake();
    $order = Order::factory()->create();
 
    (new SendConfirmationEmail)
        ->handle(new OrderCreated($order));
 
    Mail::assertSent(ConfirmationMail::class);
}

6. ¿Cuándo usar cada enfoque?

7. Regla práctica