Pourquoi je n'ai pas utilisé l'hexagonal ?
Table des matières
Voilà quelque temps que je n'ai pas parlé de mes aventures avec mon site. Je répare ce tort (et avant que le prochain projet ne commence) en vous parlant de l'architecture de l'application...
Qu'est-ce que l'architecture hexagonale ?
Le but premier de l'architecture hexagonale est de protéger le code étroitement lié avec le métier. En d'autres termes, le code qui a de la valeur et qui a toute la valeur de l'application.
Si vous avez une application de gestion de planning capable de réaliser le planning de salle de cours, des enseignants en fonction de nombreux critère, vous n'avez pas envie de perdre ce code. Ce code donne la valeur à votre application. Tout ce qui tourne autour n'a que peux d'importance au final.
Vous aller avoir tendance à protéger ce code métier et vous avez bien raison. Il doit l'être et surtout il doit dépendre d'un minimum de librairie tierce. Je dis un minimum, car selon le langage de programmation utile vous aurez des incontournables.
Et bien avec l'architecture hexagonal, le code métier qui gère le calcul des plannings correspond au "Domain".
Autour de ce code, va venir un code (que je qualifie parfois de glue) pour connecter le code du Domain avec la couche supérieure "Infrastructure", c'est la couche "Application". Ce code ne fait que transformer les structures de données, transformer les données et parfois faire passe-plat.
La couche "Infrastructure" contient le code qui interface l'extérieur avec l'application. C'est du code jetable, car dès que l'on change un élément de l'infrastructure c'est le code présent dans cette couche qui va être modifié (et en aucun cas le code du Domain).
Et voilà, on a fait un tour rapide des couches présentes dans l'architecture hexagonale. Aviez-vous remarqué que je n’ai jamais dit que c'est une architecture en couche (ou layer en anglais) ? Bah, en fait, c'est normal, car c'est représenté de façon tellement différente que parfois ce n’est pas des couches.
Alors pourquoi pas pour le site ?
Je ne sais pas si vous vous souvenez, mais quand j'ai commencé le projet, je me suis mis une date très courte pour refaire le site. Je n’aime pas les projets de refonte qui reparte de zéro. Comme j'avais peu de temps disponible, j'ai commencé par faire la liste des fonctionnalités et j'ai priorisé.
Exactement comme avec un client, le budget temps était limité, donc quoi faire dans le délai imparti ? Et c'est les fonctionnalités qui ont trinqué. J'en veux pour preuve que les commentaires ne sont toujours pas disponibles.
Dans ce contexte, il est difficile de partir sur une architecture hexagonale qui demande du temps pour mettre en place la structure de dossier, les outils pour éviter de déraper et enfin, il faut définir le "Domain".
Pour mon site c'est facile, c'est la gestion de contenu. Ai-je une façon différente des autres de gérer mes contenus ? Non, j'utilisais un Wordpress très simple !
À première vue, je n'y ai trouvé aucun intérêt. Avec le recule de nombreux mois passés a développé et faire évolué le site, je ne le vois toujours pas.
Je suis donc parti sur un développement plutôt orienté RAD (Rapid Application Development) qui me sembla plus approprié pour mon site.
Cependant, ça ne veut pas dire que le code est un plat de spaghetti ! Étant donné que le même code est utilisé pour plusieurs sites dans un seul dépôt, je me dois d'avoir une bonne organisation. Mais qui colle plus à mon besoin. J'ai donc un dossier avec la partie commune à tous les sites, puis un dossier par site contenant les spécificités.
Il est important de comprendre une architecture applicative et de savoir quand elle est intéressante ou pas. Je préfère un projet RAD bien organisé à un projet hexagonal noyer dans un CMS.
Quand est-il de la maintenance du site ?
Ayant commencé le site avec la version 6.1 de Symfony, je n'ai pour l'instant aucun problème grave de maintenance. La mise à jour version la version 6.2 et 6.3 se déroulerons sans encombre grâce à la "couche de rétro compatibilité".
Mais la version 7.0 de Symfony (qui sortira en novembre 2023) demandera plus d'effort. Et c'est là où l'on verra si le pari que je fais actuellement est gagnant.
En limitant les dépendances tierces, j'espère pouvoir monter en version 7.0 rapidement après sa sortie. Pour y arriver, je traite chaque message de dépréciation dès que possible.
Pour l'instant, j'ai travaillé sur le code du site chaque mois depuis le mois de juin pour ajouter des fonctionnalités ou réaliser quelques optimisations. La maintenance est noyée dans ce flux de travail.
Conclusion
L'architecture hexagonale, malgré toutes ces promesses, ne semble pas adapter à l'application qui gère mon site web. L'avenir nous dira si mon choix architectural pour mon site est le bon.
Pour en savoir plus ou tout simplement continuer à discuter, vous pouvez me contacter.
Consultant Expert Web, j'aide les entreprises ayant des difficultés avec leur projet Web (PHP, Symfony, Sylius).
@jbnahan69 | Macintoshplus | Linkedin | JB Dev Labs