Les réservations arrivent des quatre coins du royaume, et Gorm oublie la moitié des confirmations. La taverne se dote donc d'une volière : à chaque réservation, un corbeau part porter la confirmation.
Le contrôleur pourrait écrire le corbeau lui-même. Mais confirmer une réservation n'est pas son travail : lui, il répond au parchemin. Il va donc annoncer ce qui vient de se passer, et quelqu'un d'autre s'en occupera.
Votre mission
ConfirmationDemandee: le message. Il ne transporte que l'identifiant de la réservation.ConfirmationDemandeeHandler: le handler, qui retrouve la réservation et enregistre le corbeau :- destinataire : le nom de la réservation ;
- message :
Table réservée pour 4 aventuriers le 18/09/2026. Au plaisir !(au singulier pour un seul aventurier) ; - si la réservation a disparu, il ne fait rien — sans lever d'erreur.
- Dans
POST /api/reservations, dispatchez le message après l'enregistrement.
La volière s'affiche sur /voliere. Réservez depuis l'onglet Requêtes, puis regardez la page.
Message, handler, bus
$bus->dispatch(new ConfirmationDemandee($reservation->getId()));
Le bus transmet le message à son handler : la classe marquée #[AsMessageHandler] dont la méthode __invoke() accepte ce type de message. Aucun lien direct entre les deux : le contrôleur ignore qui traite, et le handler ignore d'où vient la demande.
Pour l'instant, tout se passe pendant la requête. Au prochain exercice, le corbeau partira en arrière-plan.
Pourquoi l'identifiant, et pas la réservation ?
Un message est fait pour voyager : il sera bientôt sérialisé, mis en file, relu plus tard. Une entité Doctrine voyage mal. Avec l'identifiant, le handler relit la réservation au moment où il travaille, donc à jour.