La fin des architectures en couches avec l’approche hexagonale (Benjamin Legros)

Рет қаралды 21,969

Күн бұрын

Pour rester informé sur l'actualité de Devoxx France, suivez nous sur twitter : / devoxxfr ou consultez notre site web www.devoxx.fr/
Attention, cette conférence peut donner des envies de refactoring ! As-tu plein d’annotations sur tes modèles ? Connais-tu un peu MVC, et les suffixes classiques Controller, Service, Repository ? Clean code, les samples de code de Spring Boot et Stack Overflow sont à peu près tes seules références d’architecture ? Dans cette conférence, on parlera des limites de ces modèles, et des différentes contraintes que cela pose sur le code. Vous découvrirez les principes de l’architecture hexagonale et de son mindset. Vous repartirez avec des exemples concrets et des différents scopes dans lesquels vous pourrez l’appliquer efficacement.

Пікірлер: 13

@EmmanuelBLONVIA 2 жыл бұрын

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 !

@ChristopheBG Жыл бұрын

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 […])

@WebUser-d4i 5 ай бұрын

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 !

@drinou3556 Жыл бұрын

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 !

@pgyejacquot 2 жыл бұрын

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 !