dav
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 ?
Je vois beaucoup de commentaires sur "trop de mocks tue le mock" concernant ce qu'est ou n'est pas un test unitaire.
Derniers commentaires :
dav
il y a presque 4 ans
Me concernant, cette vidéo est le point de départ d'un long chemin. Et la route est encore longue :) Je la conseille aussi régulièrement à droite et à gauche.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Enocre une ressource sur l'archi hexa, ça fait pas de mal !
Derniers commentaires :
dav
il y a presque 4 ans - modifié il y a presque 4 ans
Bonne remarque :) Je ne suis pas du tout expert sur le sujet, donc ma réponse est à prendre avec des pincettes. Pour moi c'est une question de nuance. Certaines classes n'auront aucun TU directement associés, car elles seront complétement couvertes par d'autres tests. D'autres seront complètement couvertes par des tests spécifiques si leur fonctionnalité est complexe.
Mais je manque d'arguments et de ressources pour détailler cette nuance :/
Mais je manque d'arguments et de ressources pour détailler cette nuance :/
Julien Sere
il y a presque 4 ans
@xtrembaker, lorsque j'ai une méthode un peu tricky comme tu dis, c'est surrement un élément important/complexe de ton business. Je te recommande alors de sortir cet élément dans une classe distincte dédié à l'implémentation de cette algo. ca te permet donc de dégager une partie "complexe" de ta classe mère, de sans doute mieux respecter le principe de single responsability
Ca te permettra de faire peut etre apparaitre mieux dans ton code un concept métier (si méthode compliqué c'est bien que c'est un point sensible métier normalement)
En le mettant dans une classe dédié, tu pourras aussi le remplacer plus simplement (par exemple ca devient facile de remplacer l'appel de cette classe dédié par une interface et ca ouvre la porte à la possibilité de switcher facilement d'implémentation, imagine que tu as une idée pour améliorer l'algo en question ou améliorer sa vitesse, bim ca devient possible facilement par le fait que tu ai extrait l'algo dans une classe dédié)
Ca te permettra de faire peut etre apparaitre mieux dans ton code un concept métier (si méthode compliqué c'est bien que c'est un point sensible métier normalement)
En le mettant dans une classe dédié, tu pourras aussi le remplacer plus simplement (par exemple ca devient facile de remplacer l'appel de cette classe dédié par une interface et ca ouvre la porte à la possibilité de switcher facilement d'implémentation, imagine que tu as une idée pour améliorer l'algo en question ou améliorer sa vitesse, bim ca devient possible facilement par le fait que tu ai extrait l'algo dans une classe dédié)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Enocre une ressource sur l'archi hexa, ça fait pas de mal !
Derniers commentaires :
dav
il y a presque 4 ans - modifié il y a presque 4 ans
Bonne remarque :) Je ne suis pas du tout expert sur le sujet, donc ma réponse est à prendre avec des pincettes. Pour moi c'est une question de nuance. Certaines classes n'auront aucun TU directement associés, car elles seront complétement couvertes par d'autres tests. D'autres seront complètement couvertes par des tests spécifiques si leur fonctionnalité est complexe.
Mais je manque d'arguments et de ressources pour détailler cette nuance :/
Mais je manque d'arguments et de ressources pour détailler cette nuance :/
Julien Sere
il y a presque 4 ans
@xtrembaker, lorsque j'ai une méthode un peu tricky comme tu dis, c'est surrement un élément important/complexe de ton business. Je te recommande alors de sortir cet élément dans une classe distincte dédié à l'implémentation de cette algo. ca te permet donc de dégager une partie "complexe" de ta classe mère, de sans doute mieux respecter le principe de single responsability
Ca te permettra de faire peut etre apparaitre mieux dans ton code un concept métier (si méthode compliqué c'est bien que c'est un point sensible métier normalement)
En le mettant dans une classe dédié, tu pourras aussi le remplacer plus simplement (par exemple ca devient facile de remplacer l'appel de cette classe dédié par une interface et ca ouvre la porte à la possibilité de switcher facilement d'implémentation, imagine que tu as une idée pour améliorer l'algo en question ou améliorer sa vitesse, bim ca devient possible facilement par le fait que tu ai extrait l'algo dans une classe dédié)
Ca te permettra de faire peut etre apparaitre mieux dans ton code un concept métier (si méthode compliqué c'est bien que c'est un point sensible métier normalement)
En le mettant dans une classe dédié, tu pourras aussi le remplacer plus simplement (par exemple ca devient facile de remplacer l'appel de cette classe dédié par une interface et ca ouvre la porte à la possibilité de switcher facilement d'implémentation, imagine que tu as une idée pour améliorer l'algo en question ou améliorer sa vitesse, bim ca devient possible facilement par le fait que tu ai extrait l'algo dans une classe dédié)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
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.