event-dispatchlisted

# /event-dispatch — Créer et dispatcher un événement custom > **Utilise quand** tu crées un événement applicatif et l'émets via `EventDispatcherInterface`. > **Pas quand** tu écoutes un événement existant → `/symfony:event-listen` (single callback) ou `/symfony:event-subscribe` (multi-callbacks). Tu ouvres un **point d'extension** dans ton code : un moment où d'autres parties de l'application (ou de futurs bundles) peuvent brancher du comportement sans toi. Tu définis la classe d'événement, tu injectes `EventDispatcherInterface`, tu dispatches — et tu laisses les listeners / subscribers (voir `/symfony:event-listen`, `/symfony:event-subscribe`) s'y accrocher. ## Détection préalable (obligatoire) 1. Lire `composer.json` — vérifier `symfony/event-dispatcher-contracts` (tiré par `symfony/framework-bundle`). Le contrat est suffisant côté émetteur. 2. Vérifier que le cas ne se résout pas déjà avec un événement kernel existant (`kernel.response`, `kernel.controller`). Si oui, écouter l'événement framework plutôt qu'en créer un custom. 3. Se demander : **l'événement a-t-il un usage externe ?** Si personne d'autre n'écoute, un simple appel de service direct est souvent plus clair. Créer un événement n'a de sens que pour : - Ouvrir un point d'extension public (bundle, plugin), - Découpler un effet de bord transverse (audit, indexation, notification) du flux principal, - Offrir une sémantique before/after (permettre à des tiers de muter l'input ou d'enrichir l'output). ##