Aller au contenu
AFUP AFUP Day 2025 Baromètre Planète PHP PUFA
 

Publier des domain events sans RabbitMQ, c’est possible !

Description

Dans une approche DDD (Domain Driven Design), la publication de Domain Events permet la communication entre différents Bounded Contexts (périmètres métiers autonomes et isolés). Vous refusez de complexifier votre application avec une couche supplémentaire de messaging ? Vos ops ne sont pas favorables au déploiement de RabbitMQ ? Nous verrons à travers un exemple concret qu’il est possible de s’en passer.

Conférence donnée lors du Forum PHP 2016, ayant eu lieu les 27 et 28 octobre 2016.

Informations complémentaires

Vidéo

Les speakers

Simon DELICATA

Fort d'une expérience de plus de 10 ans en tant que lead développeur et responsable technique, Simon Delicata a été co-fondateur d’une web agency spécialisée dans l’immobilier avant de rejoindre Alptis Assurances. Passionné par les méthodes de développement, la conception et l’architecture, il est intervenu sur tous types de projets : portails institutionnels, sites à fort trafic, e-commerce, framework, extranet, plate-forme de streaming, BPM...

Julien SALLEYRON

Utilisateur de PHP depuis plus de 10 ans, Julien Salleyron a participé à plusieurs projets open-source, notamment l’un des premiers frameworks PHP. Aujourd’hui Architecte Technique au sein de la société Alptis Assurance, il est sans cesse soucieux des problématiques de performances, de stabilité et d’industrialisation. Il est également le lead developpeur de l’extension AOP PHP.

Commentaires

J'ai beaucoup aimé ce talk, l'approche de développement par événements m'a semblé très intéressante. Le talk met bien en lumière les différentes implémentations possibles et l'utilisation des Domaines Events.
Kenny Durand, le 28/10/2016
Bolbo, le 29/10/2016
L'intro était un peu longue mais très bonne. Un fois que les concepts se sont mélangés je n'ai pas réussi à comprendre ce qu'on essayait de faire. Au niveau RabbitMQ/pas RabbitMQ je n'ai pas été très convaincu : RabbitMQ ça demande du boulot à mettre en place mais pour l'équipe ops, pas les dev. Mais la solution inverse (sans RabbitMQ) me semble encore bien plus compliquée en terme de dev et d'ops (donc pas de gain ici), et comme vous l'avez dit aux questions moins stable, scalable, fail-safe, monitoré, etc. Du coup j'imagine mal l'équipe ops être partante pour gérer ça par rapport à un RabbitMQ au final. Cela dit le message a probablement eu du mal à passer parce que j'ai été perdu à un moment, on sent qu'il y'a eu beaucoup de boulot derrière tout ça.
Matthieu Napoli, le 29/10/2016
approche intéréssante et un bon tips pour éventuellement migrer sur RabbitMQ si besoin
Ulrich, le 31/10/2016
Beaucoup de boulot ! En revanche, je n'ai pas bien compris en quoi se passer de RabbitMQ était un avantage..
lnc, le 31/10/2016
Passé le débat RabbitMQ vs custom, j'ai beaucoup apprécié les rappels sur CQRS+ES.
Alexandre Balmes, le 03/11/2016