Hands-on Front : La clean architecture dans le web
ฝัง
- เผยแพร่เมื่อ 7 ก.พ. 2025
- Après avoir découvert les principaux frameworks de développement d’application frontend au travers des précédents « hands-on », nous allons maintenant voir comment architecturer notre application. L’objectif d’une bonne architecture est de gagner en testabilité, évolutivité et maintenabilité. Nous verrons aussi qu’une bonne architecture nous permettra de moins dépendre des frameworks et outils pour développer des applications plus résilientes au changement de technologies.
Le concept de « Clean Architecture », qu’on appelle aussi l’« Architecture hexagonale » ou encore « Ports/Adapters Architecture » a déjà fait ses preuves dans le développement d’application backend. Si cette technique a gagné en popularité ces dernières années, elle ne s’est pas beaucoup démocratisée dans le développement d’application frontend.
Nous vous invitons donc à venir découvrir les fondamentaux de la Clean Architecture et voir comment l’implémenter dans une application web. À travers cette session, nous redévelopperons l’application de prévision météorologique à partir des concepts de « Clean Architecture » puis nous tenterons de migrer de frameworks en live.
Lien du répo pour proposer vos PR et regarder comment on implémente la clean architecture : github.com/Zen... - บันเทิง
Super vidéo ! La séparation en deux dossiers "domain" et "infrastructure" est top, ca apporte beaucoup de clarté ! Vive la clean archi ! ;-)
merci pour la video
Au sein des frameworks frontend actuels je ne vois pas l'utilité d'appliquer les principes de presenteurs / controlleur sachant que c'est le rôle natif des composant de jouer le rôle de présenteur et de controlleur
Les abstraire c'est faire du framework une abstraction (comme vous l'avez fait dans le projet de démo que vous avez présenté) ce qui est très certainement overkill pour la majorité des cas pratiques
Cependant bravo pour cette démonstration
Si c'est pour "garder le framework a distance de bras" prendre un framework all in one comme angular n'as plus d'intérêt non ? Les trucs comme @injectable ne sont pas utilisable car sinon on aurait de l'angular dans le domain. Mais d'un autre côté pour profiter pleinement d'angular il faut se marier avec lol et là le framework se propage dans toute la codebase ce qui n'est pas du tout "clean archi". J'ai l'impression que "angular + séparer framework et domaine" = beaucoup de boilerplate
Salut Fabien !
Je pense que tout dépend de la taille de l'application et du contexte ;)
Oui 100% d'accord avec toi pour ne pas utiliser l'injection de dépendance d'angular dans le domaine sinon ça va à l'encontre de la séparation domaine/infra. En revanche, l'injection de dépendance d'angular est très pratique pour injecter le domaine dans les composants d'UI. Je suis aussi en pleine réflexion à l'idée d'intégrer rxjs dans le domaine, beaucoup d'avantages, mais le gros problème c'est qu'on devient dépendant de la librairie.
Bon après on rentre aussi dans une guerre du choix de framework. Un jour si j'ai le temps, je ferai l'exercice sans framework :)