Architecturoplastie hexagonale d’un backend: Opération à code ouvert (Julien TOPÇU, Adrien JOLY)
Vložit
- čas přidán 13. 09. 2024
- Voxxed Days Luxembourg 2023
Room: BSD
Type: University
Votre backend n'a même pas 3 ans et pourtant, il n’est pas en forme. Il devient difficile d’y ajouter de nouvelles fonctionnalités, de maintenir et/ou de refactorer l’existant. Le code est intolérant à la montée de versions de librairies, pouvant lui causer une régressionnite fonctionnelle aiguë. Les tests deviennent douloureux à l’écriture.
Les précédents choix techniques ont comme effet secondaire de limiter ou verrouiller l’évolution du logiciel, à un point où il devient tentant de repartir de zéro. Votre backend commence lentement à pourrir, son architecture s’étant sclérosée.
Mais savez-vous qu’il existe différents types de complexité logicielle ? Et que bien les identifier en les séparant avec un pattern d’architecture adapté, peut améliorer la pérennité de nos applications ? Et tout ça, quels que soient les frameworks que vous utilisez ?
Dans cette opération à code ouvert sous forme d’un mob-programming intéractif, venez découvrir comment redonner un coup de jeune à votre backend à bout de souffle en le faisant migrer vers de l’Architecture Hexagonale.
Excelente présentation ! toujours au top Julien
Super talk, merci
Excellente présentation, regardée du début à la fin. Merci.
Excellent !!!
Julien Topçu et Adrien Joly toujours au top ! Excellent talk de Shodo, félicitations ❤
J'ai cependant une question qui me taraude un peu sur le passage "c'est pas vrai, en DDD, on est pas obligé de persister [l'agrégat] en entier". czcams.com/video/r_x_sEDCV1Y/video.html
Je suis pas sur du sens que Julien veut donner à cette phrase, et aurais aimé plus de détails sur la ou les exceptions à ce qui est à mon sens une règle importante en DDD.
Est ce qu'on parle du fait que potentiellement l'agrégat aurait été mal choisi dans le contexte de gestion de playlist ?
D'une stratégie qui consiste à manipuler un agrégat en invoquant un repository d'une entité dont est composé l'agrégat / insert via la relation de l'aggrégat ?
De mes lectures, il est souvent ressorti la règle qu'un repository ne doit manipuler qu'un agrégat, et donc insérer en base la projection "model de persistence" de celui-ci.
Qu'en pensez vous ?