Forum PHP 2015
23 - 24 Nov 2015 at Beffroi de Montrouge

Retour d'expérience très intéressant. En espérant que ça donne des idées à d'autre speaker pour en avoir d'autres.

4 pouces parce que cette présentation a éveillé tout mon intérêt et que je suis fortement intéressé par son essai.

Un pouce de moins pour la forme : je trouve que tu es passé un peu vite sur le pattern "Specification" pour que ça soit clair, et tu as perdu un peu trop de temps avec une présentation hors Rulerz.
C'est mon ressenti, c'est juste de la forme.

En tout cas, bravo pour Rulerz, et longue vie à ce projet !

Merci à tous pour vos retours.

Pour Guillaume et Alexandre : même si ce n'est pas obligatoire, l'ES est très souvent utilisé en CQRS. Le titre aurait pu le mentionner, je vous l'accorde. J'ai une préférence pour les titres simples, c'est surement une erreur. Petite subtilité cependant, la démarche n'était pas de dire "regarder comment CQRS+ES a solutionné nos problèmes" mais "On s'est lancé dans CQRS+ES, on s'est retrouvé confronté à des problèmes et voici les solutions qu'on a identifié". J'ai eu à accélérer ma diction au moment des problèmes et n'ai visiblement pas été clair sur la démarche.

Pour Samuel, tu peux jeter un oeil à Broadway qui fournit des implémentations des objets de base (AggregateRoot, CommandBus, EventBus, ...). Je ne l'ai pas mentionné car on n'en a pas utilisé volontairement. Cela représente un volume de code très faible et l'apport d'un framework est très parcellaire (une interface par çi, une classe abstraite par là) et au final peu structurant. On a préféré implémenter les concepts de base nous-mêmes pour mieux les appréhender (encore fois on parle de quelques heures de travail au total seulement). Sinon au milieu de la présentation, il y a le lien d'une conf formidable sur le sujet, aussi bien orienté technique que business (2h).

Pour Olivier, je partage ton constat sur le manque de REXP par rapport aux conférences d'introduction, purement théoriques. Ce constat fut le leitmotiv de ma participation. A l'époque du CFP, les conférences étaient de 40 min et non 30 (même si au final, en tant que spectateur j'ai trouvé la durée de 30 min plus agréable). Tout le dilemne d'un créneau de 30 min étaient de rappeler les bases pour permettre à tout le monde de suivre et avoir assez de temps sur les retours d'xp pour apporter une plus value. J'ai travaillé des heures pour ajuster ce difficile équilibre. J'aurai aimé ne parler que de l'implémentation mais CQRS n'est pas assez populaire et répandu. Cela aurait été une erreur. Tu peux me contacter si tu veux plus de détails, j'y répondrai avec plaisir.

Encore merci pour vos retours détaillés. A votre disposition pour des questions complémentaires.

A nouveau, merci aux commentateurs :)

Pour répondre aux "critiques" (je mets des guillemets pour souligner que j'en perçois l'aspect constructif et non trollesque :)) d'Olivier :

J'ai trop peu fréquenté les SSII pour avoir été imprégné de leurs méthodes :) Je suis d'accord avec la majorité de tes remarques, et à titre personnel, je ne peux pas dire que faire ce travail d'archi m'exalte plus que ça...

Comme tu l'as fait remarqué, je n'ai pas précisé explicitement à qui s'adressait cette présentation. C'est sans doute parce que je ne suis pas aussi provocateur que ma réputation le laisse parfois croire :) Clairement, il n'est pas possible de considérer que tous les développeurs sont également compétents. Alors que pour des gens comme toi, comme beaucoup d'autres participants du Forum, ou encore moi-même, ces recommandations apparaissent comme un peu laborieuses, j'en conviens.

Mais mon job, ce n'est hélas pas la R&D, et les équipes avec lesquelles je travaille le plus souvent ont besoin de ce niveau d'encadrement du projet pour que les projets n'explosent pas en vol, notamment en terme de délai et de qualité. Il y a beaucoup de développeurs juniors sur le marché (je ne parle pas d'âge mais d'approche et d'expérience... 10 fois un an d'expérience, ça ne fait pas forcément 10 ans...), et leur niveau de productivité lorsqu'on leur demande à la fois d'adopter des outils qu'ils maîtrisent mal et qu'on leur laisse trop de responsabilité sur l'archi, est souvent catastrophique.

Enfin, mon propos ne s'oppose en aucun cas à la mise en ouvre de micro-services, ni a rien d'autre de ce que tu proposes : je n'ai d'ailleurs suggéré aucune archi :) Je dit juste qu'il est préférable que quelqu'un prenne les responsabilités des choix d'archi. Encore une fois, faire le choix de ne pas en faire reste un choix, et je ne le conteste pas a priori. Ca dépendra de l'équipe, de son niveau de compétence, de son envie de s'investir sur cette partie du job, etc.

Quoiqu'il en soit, merci pour ton commentaire très développé, qui me permettra d'adapter la forme de mon propos pour éviter les malentendus à l'avenir.

Pour ceux qui étaient curieux de la transformation SCRUM de l'équipe, les slides de la présentation faite à l'Agile Tour par Guillaume Magnier sur la transformation sont disponibles à cette adresse : http://fr.slideshare.net/GuillaumeMagnier/passer-scrum-avec-45-personnes-rtrospective-step-by-step

N'hésitez pas à le contacter !

I was expecting more reasons on "why everyone wins with framework agnostic code", but the talk was more on the history of tools in PHP.

It was a great talk, but it wasn't the subject I was expecting to see.

J'ai eu l'impression de retourner en SSII et de devoir pondre mes bons vieux DAT, MPD, MCD, et déployer le boilerplate de l'équipe pour qu'elle puisse attaquer la conception avec la plupart des problèmes réglés.

Aujourd'hui, je crois de plus en plus dans l'architecture émergente, la refacto continue, et j'aime beaucoup ce que disent Uncle Bob ou Greg Young à ce sujet.

Je dis pas qu'il ne faut pas d'archi et se lancer tête baissée dans un projet, mais je pense que les méthodos actuelles nous permettent de baisser un peu ce curseur et d'économiser du temps pour avancer plus vite sur le produit, ce qui est notamment le nerf de la guerre dans le domaine des startups.

Enfin et puisque les microservices sont à la mode de nos jours, ce type d'archi permet notamment de limiter la casse d'un côté si l'archi a été sous-estimée (moins de refacto par domaine car ils sont plus simple, et on n'attaque pas tout d'un coup), mais d'un autre côté c'est aussi dans ce type d'archi que le temps consommé par la phase d'architecture est la plus rentable car elle peut être réexploitée pour chaque MS.

Ca manquait un peu de pourquoi, et à qui ça s'adresse ? Trop générique à mon goût.

J'ai bien aimé le talk, par contre j'aurai aimé un peu plus de temps sur les retours, plus d'exemples etc...
BTW, c'était plus axé Event Sourcing que CQRS.

L'inconvénient avec ce genre d'architecture, c'est qu'il y a très peu de retours d'expérience concrets, avec du vrai code de prod (ou autre chose que les samples bêtes et méchants qu'on peut trouver sur broadway par exemple) à montrer.

Ayant vu beaucoup de conf (Greg Young, Eric Evans, ...), j'espérais voir très peu de théorie et beaucoup de pratique, car il y a peu de ressources techniques et implémentations visibles aujourd'hui sur le net !

Nice talk anyway !