Events and Listeners: When and How?

Another possible option for "tasks in the background" is to call the Event in the Controller and allow different classes (current ones or future ones) to "listen" to that event.

This is the whole logic behind events/listeners: future-first thinking. You are opening the system for other developers to add their listeners in the future easily.

Imagine the scenario: you need to inform the system that the new user is registered. And then, as one of the Listeners, we want to update a Monthly Report. So first, let's make an Event class:

php artisan make:event NewUserRegistered

And a Listener:

php artisan make:listener MonthlyReportNewUserListener --event=NewUserRegistered

Now we can dispatch the Event in the Controller, similar to a job:

use App\Events\NewUserRegistered;
 
// ...
 
public function store(StoreUserRequest $request)
{
    $user = (new CreateUserAction())->execute($request->validated());
    NewUserDataJob::dispatch($user);
 
    NewUserRegistered::dispatch($user); 
    //
}

Inside the Event, we won't perform any actions, but we need to accept a User, so every Listener class would have...