L'architecture hexagonale, une approche qui honore principalement l'un des cinq principes SOLID : l'inversion de dépendances !
Peut-être avez-vous déjà éprouvé certaines difficultés dans du code "spaghettis" à démêler les origines d'un bug. Une simple modification en un point du code et tout se casse, vos tests échouent ! Le pire, c'est que la modification a été faite dans une page web de votre application, pourtant ce sont vos tests métier qui échouent… Aïe, aïe, aïe, votre application est toute entremêlée et cela va être un enfer à maintenir !
Trois mois plus tard…
Enfin, le bug est corrigé, ce ne fut pas une mince affaire ! Bon le code est incompréhensible, et on n'a pas eu le temps de tout retravailler, mais au moins la correction est là et elle fonctionne !
Quand soudain...
Chef : "Bon le client souhaite désormais utiliser notre application directement en mode console ou script afin d'automatiser certaines tâches ! Cela demandera-t-il beaucoup de travail ?"
Développeur : "Je vais te faire une estimation !"
Dans la tête du développeur : "Là, on est mal !"
Si seulement j'avais appliqué l'architecture hexagonale, alors…
Ma page web n'aurait pas impacté mon domaine métier
Dans l'architecture hexagonale, le domaine ne dépend pas des implémentations concrètes des modules externes. C'est là le principe d'inversion de dépendances des principes SOLID. De ce fait, le domaine est complètement indépendant de la manière dont il est utilisé. Ainsi, une modification dans une page web n'impactera pas le domaine, et l'exemple de bug cité ne pourrait plus se produire. Une architecture hexagonale fait donc gagner en terme de maintenabilité et de robustesse de notre application.
J'aurais pu mettre en place un mode script sans modifier le code existant
Le domaine étant indépendant de la manière dont il est utilisé, si un nouveau module doit être implémenté afin d'utiliser le domaine, alors il n'y aura pas besoin de modifier le code métier. Le nouveau module client pourra directement consommer les services offerts par le domaine.
J'aurais pu avoir des tests automatisés qui couvrent ma logique métier de manière isolée
La logique métier, les besoins profonds du métier doivent être implémentés dans le domaine. Quand on parle de besoins aux clients, ils ont parfois du mal à l'exprimer, à faire la différence entre le besoin (le service à rendre), et la manière d'utiliser ce besoin.
Exemples :
- Je souhaite qu'un message rouge "Erreur du champs numéro 3" apparaisse quand il y a une erreur dans le champs numéro 3 du formulaire.
Ceci ne constitue pas le besoin, mais bien la manière dont le besoin sera rendu à l'utilisateur. La couleur du message, voire même le contenu pour l'utilisateur ne constituent pas le besoin. - Je souhaite être informé quand il y a une erreur sur le code postal saisi.
Ici, on ne précise plus la couleur, ou le contenu du message, mais bien le besoin : valider les entrées lors de l'enregistrement d'une donnée. Le domaine devant être intègre, cette validation doit être faite dans le domaine. Si elle était faite dans la "vue" uniquement, alors rien n'empêcherait un autre module de déstabiliser notre application avec des données erronées.
Pour ces raisons, des tests automatisés sur le domaine permettent de valider que la logique métier fonctionne, indépendamment des modules qui l'entourent. Cette indépendance est offerte par l'architecture hexagonale.
Conclusion : L'architecture hexagonale, le choix de la modularité
L'architecture hexagonale permet de garantir une haute modularité des entités externes au cœur de notre application. Cette modularité offre des avantages tels que la robustesse du cœur de notre application, la possibilité de remplacer facilement un module par un autre sans impacter l'existant, ou encore la capacité d'ajouter des modules externes sans affecter notre domaine métier.
