Est-ce que les frameworks et l'architecture hexagonale font bon ménage ?
Y-a-t-il des projets qui s’adaptent mieux que d’autres avec de l’hexa ou du framework ?
Quelles sont les contraintes, les atouts ?
Comment choisir et adapter son projet à l'une de ces 2 patterns ?
On en parle dans l’épisode du jour avec Romain Fallet.
Pour suivre Romain Fallet sur Linkedin : https://www.linkedin.com/in/romain-fallet/
Pour découvrir Tolk : https://www.tolk.ai/
Pour découvrir le cursus Artisan Développeur : https://ad302.fr/KmhYNl
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Merci pour ce podcast très chouette, j'ai particulièrement apprécié la partie sur la gestion/priorisation de la dette technique liée à l'absence d'archi hexa.
J'aurais bien aimé quelques précisions sur le fait de switcher vers de l'archi hexa avec Rails. Qu'entends-tu Benoit précisément ? Sur le sujet rails/harchi hexa j'ai la référence suivante que j'avais trouvée très intéressante : martinfowler.com/.... Ce que j'en ai retenu : si le métier s'y prête, il peut être pertinent de partir sur du Rails, donc avec la partie sgbd dans l'hexagone. En revanche cela n'empêche pas de faire de l'hexagonal sur les interactions que l'on considère à droite de l'hexagone, comme les appels vers d'autres partenaires. Et ce point me fait réagir aussi sur la définition de l'archi hexa qui serait "une standardisation du principe d'inversion de dépendance". L'inversion de dépendance me semble effectivement un point important de l'archi hexa, mais l'isolation des modèles (le côté anticorruption layer de l'archi) me parait tout aussi important et n'a pas été évoqué. Car on peut avoir de l'inversion de dépendance, mais se trimballer des objets d'api comme modèle métier, et ça, c'est bien galère :)
Bonne remarque.
Vis-à-vis de rails, mon point est simplement de dire que l'hexa dénature par mal le framework.
Si c'est pour faire ça, autant partir sur autre chose (ou créer un autre framework ?).
Ce n'est que mon avis.