Slab

Apparence

Les événements ​

Quand quelque chose d'important se produit dans le domaine — une commande est passée, un statut change, un compte est créé — le cœur émet un événement. Vous y réagissez par un listener, sans modifier le code qui l'émet.

Le problème ​

À la validation d'une commande, il faut envoyer un e-mail de confirmation, décrémenter le stock, notifier un ERP… Ces réactions appartiennent à des packages différents, et le cœur ne doit en connaître aucune. L'événement est le point de découplage.

Le principe ​

Le cœur émet ; plusieurs listeners écoutent, indépendamment.

Les événements de domaine ​

ÉvénementQuand
OrderPlacedcommande créée et persistée
OrderStatusChangedchangement de statut de commande
CartItemAdded / CartItemUpdated / CartItemRemovedmodification du panier
CartMergedfusion panier invité → compte
UserRegistered / UserEmailChangedcycle de vie du compte
CurrencyChangedchangement de devise
ReindexRequesteddemande de réindexation produit

La liste à jour est dans la référence.

Écouter un événement ​

Dans un package, l'écoute se déclare explicitement (un provider vendor n'a pas l'auto-découverte des listeners). Le plus simple, au boot() :

php
use Illuminate\Support\Facades\Event;
use Slab\Framework\Core\Order\Events\OrderPlaced;

Event::listen(OrderPlaced::class, function (OrderPlaced $event) {
    // $event->order : la commande figée
    NotifierErp::dispatch($event->order); // déléguez à un Job pour ne pas bloquer la requête
});

Pour une vraie feature, préférez un EventServiceProvider dédié avec un listener dédié (queueable) — c'est ce que fait le cœur pour l'e-mail de statut de commande.

Émettre vos propres événements ​

Rien ne vous empêche de définir et d'émettre vos événements dans votre package (MonEvent::dispatch(...)) pour que d'autres parties s'y branchent. En revanche, les événements du cœur restent émis par le cœur : vous les écoutez, vous ne les déclenchez pas à sa place.

Voir aussi ​