L’article explique comment utiliser Symfony Messenger pour gérer les événements du domaine sans créer de couplage excessif. L’idée principale est de séparer clairement l’interface du domaine (ports) de l’implémentation technique (adaptateurs), en s’inspirant de l’architecture hexagonale. Ainsi, le domaine reste indépendant du framework, utilisant des interfaces comme DomainEvent et EventBus pour publier des événements sans dépendre de Symfony Messenger.
L’auteur illustre cette approche avec un exemple concret : un événement OrderPlaced est défini comme une classe PHP simple, sans annotations ni dépendances vers Messenger. Les agrégats du domaine enregistrent ces événements dans une collection interne, puis l’application les publie via une implémentation de EventBus qui utilise Messenger en arrière-plan. Cela permet de changer de transport (AMQP, Redis, etc.) sans modifier le code métier.
Enfin, l’article souligne l’importance de maintenir cette séparation pour éviter les problèmes de couplage, comme des noms de classes ou de namespaces qui briseraient le code en cas de modification du framework. L’objectif est de conserver une architecture propre et maintenable, où le domaine reste au centre et les détails techniques en périphérie.
Cet article de Wanadev Digital explique comment utiliser l'Event Bus de Symfony Messenger pour créer une architecture découplée. Il compare l'EventDispatcher et l'Event Bus, soulignant leurs différences fondamentales : synchrone vs asynchrone, couplage faible vs fort, et scalabilité. L'Event Bus permet un traitement asynchrone, une sérialisation des messages, et une meilleure traçabilité. L'article guide pas à pas pour configurer et utiliser l'Event Bus, idéal pour des tâches comme l'envoi d'emails ou la génération de PDF. Prérequis : comprendre les concepts de Commands et Queries.
L'auteur explique pourquoi repenser les architectures logicielles en privilégiant les événements plutôt que les requêtes synchrones. Au lieu de s’appuyer sur le modèle classique « demande/réponse », l’approche event-driven (EDA) émet des faits immuables (ex : UserSignedUp, OrderPlaced) via des brokers (Kafka, RabbitMQ, etc.), permettant un découplage total, une scalabilité asynchrone et une observabilité native. Les avantages sont majeurs : flexibilité, extensibilité sans modifier les sources, et traçabilité des actions. Des géants comme Shopify, Netflix ou Stripe l’utilisent pour synchroniser des services, déclencher des workflows ou alimenter l’analytics. Attention cependant aux pièges : surcharge des payloads, absence d’idempotence, ou manque de versioning. L’EDA n’est pas une solution universelle (coûts, complexité accrue), mais elle transforme la résilience et l’évolutivité des systèmes — à condition d’adopter une discipline rigoureuse et de traiter les événements comme des contrats versionnés.
L'auteur montre, avec un exemple simple, comment utiliser Symfony Messenger pour découpler son code (traitement de statistiques de navigation)
Uncle Bob explique sa prise de conscience qu'il ne faut pas hésiter à utiliser des structures de classe dans la programmation fonctionnelle, même quand le langage (ici le clojure) ne dispose pas de mot clef spécifique pour ça. L'idée est de bien classer les données / méthodes qui vont bien ensemble.
Une place pour toute chose, chaque chose à sa place
Tout est dans le titre. Pour citer l'auteur : "On a exprimé le but de l'action de l'utilisateur (pourquoi veut-il faire ça) au lieu du moyen (comment faire ça). On a utilisé des verbes au lieu des noms.
En s'affranchissant du comment au profit du pourquoi, on y gagne du découplage"
Tout est dans le titre
Un résumé de mes notes du ForumPHP, les 27 et 28 octobre 2016 : le second jour
Tout est dans le titre
Très intéressant (marche évidemment pour tous les frameworks, mais l'auteur s'attarde ici sur Symfony2)