php - naming Laravel events, listeners and Jobs -

i have event called userwasregistered have listener called userwasregistered there intned develop job commands called:

emailregistrationconfirmation

notifyadminsnewregistration

createnewbillingaccount

all these jobs executed within userwasregistered event listener class.

is correct approach or should have multiple listeners userwasregistered? feel using jobs approach enabled me call "jobs" other areas in application @ different times. e.g. calling createnewbillingaccount might called if user changed details...?

i recommend change listener names that's more explicit what's happening, i'd avoid directly pairing listeners events.

we're using anemic event/listener approach, listeners pass actual task "doers" (jobs, services, name it).

this example taken real system:

app/providers/eventserviceprovider.php:

    orderwaspaid::class    => [         provideaccesstoproduct::class,         startsubscription::class,         sendorderpaidnotification::class,         processpendingshipment::class,         logorderpayment::class     ], 

startsubscription listeners:

namespace app\modules\subscription\listeners;   use app\modules\order\contracts\ordereventinterface; use app\modules\subscription\services\subscriptioncreator;  class startsubscription {     /**      * @var subscriptioncreator      */     private $subscriptioncreator;      /**      * startsubscription constructor.      *      * @param subscriptioncreator $subscriptioncreator      */     public function __construct(subscriptioncreator $subscriptioncreator)     {         $this->subscriptioncreator = $subscriptioncreator;     }      /**      * creates subscription if order subscription order.      *      * @param ordereventinterface $event      */     public function handle(ordereventinterface $event)     {         $order = $event->getorder();          if (!$order->issubscription()) {             return;         }          $this->subscriptioncreator->createfromorder($order);     } } 

this way can invoke jobs/services (subscriptioncreator in example) in other areas of application.

it's possible bind listener other events well, other orderwaspaid.