Une des meilleurs présentation en français que j'ai eu l'occasion de voir. C'est clair, ça va à l'essentiel, pas de chichi et surtout une bonne maîtrise du sujet par l'orateur. L'architecture Hexagonal, pas si compliquée à comprendre mais toujours un peu dissuasif de part la multiplication des classes et du code. Mais un excellent moyen d'isoler son domain/modele. Bravo Benjamin Legros !

Tout est très clair, on a toutes les informations dont on a besoin. Merci !

Super présentation. On resent la maîtrise. Très humble et drôle en plus 👏

Superbe présentation, et belle démonstration de l'intérêt de l'architecture Hexagonale.

Super explication !

Trés clair avec ttes les informations necessaires entre les classes.

@DevoxxFRvideos

2 жыл бұрын

Merci bien

Super clair, bien vulgarisé, rien à redire 🙂

31:30 Je trouve toujours très MAL POLI de sortir d'une salle de présentation alors que la conf n'est pas complètement terminée. C'est un gros manque de respect pour le présentateur même si la partie principale est terminée et que certains participants ont d'autres choses à faire. Attendre juste 10 minutes que tout soit complètement terminé ne coute rien. Merci à Benjamin LEGROS pour cette belle et instructive présentation !

thank u

Super présentation Benjamin, merci beaucoup. Serait il possible d'accéder au GIT du code que tu présentes pour revoir le code final avec précision ? merci en tous les cas, très ludique et fun !

Je trouve que c’est parfois approximatif et confus On parle d’architecture ports et adapters pour dire ensuite : les ports sont des interfaces et les adapters des implémentations. Ça c’est juste vrai à droite, à gauche non. Déjà pas d’interface obligatoire (mais c’est dit à la toute fin pendant les questions), et si on mettait une interface, l’adapter n’est pas une implem…l’adapter c’est le contrôleur. Il est dit que « application » est « la couche de persistance ou le broker » alors qu’en hexagonale c’est le centre de l’hexagone. En parlant de DDD, on explique que le service contient la logique business alors que c’est le modèle qui doit la posséder. Toujours en DDD, la méthode « save » du repository est un très mauvais nommage car on parle de découpler la technique du métier mais on utilise un terme technique: Pour CQRS et event sourcing, ça n’a pas trop de rapport avec le thème et ça complexifie le discours. Pareil pour les microservices où on l’explique via un découpage alors que celui-ci est orthogonale avec la façon de déployer (monolithe vs microservices) Enfin, il est dit que l’archi n’est pas adaptée au batch alors que c’est justement la citation du début (sauf que le terme batch a été remplacé par un […])

@user-vz9cj1ox3m

Ай бұрын

Toutes les personnes qui parlent de clean architecture DDD racontent les mêmes salades. On dit qu’il ne faut pas des setter et constructeur car techniques. Sauf que les getter, une classe, une interface, une énumération sont des notions technique. L’isolation du domain de la technique est un faux problème car même isolé si la technique change le métier est quand même impacté car l’application (infra + domain) sont au sens livraison, fortement couplés (le domaine ne peut pas tourner sans la technique). Si la technique change, on sait que le domaine n’est pas impacté grâce aux TESTsssss !!!!!!!!! Le code a pour but de traduire le métier en technique. Faut pas l’oublier ! Appliquer un peut de clean code dans votre code et sa suffit !