Architecture hexagonale: Partie 2

Cet article est la deuxième partie d’une explication sur l’architecture hexagonale. Elle se décompose en 2 partie, le début se trouve ici. Le but de cette suite est de faire un exemple complet, partir vraiment dans la pratique. Si tu veux plus d’information théorique sur l’architecture hexagonale, tu peux lire cet article.

J’ai fait évoluer mon application hexagonale pour les bibliothèques, afin de comprendre les interactions entre hexagones. Tu trouveras tout le code source dans ce repository git. La commande maven “clean install” sera peut être nécessaire au niveau du module parent pour faire marcher l’application. Je te conseille fortement de regarder mon premier article sur l’architecture hexagonale pour commencer, où se trouve le besoin métier.

Découpage et frontières métiers

Dans le DDD, une application découpe son domaine en frontière appelée “bounded context”. Chaque hexagone doit avoir ses propres frontières bien définies. Ainsi, pour mon application, j’ai découpé en 3 hexagones.

• J’ai un premier contexte que je vais appeler “data”. C’est la donnée liée à mes livres. Par exemple, je peux avoir un livre “Harry Potter” dans une bibliothèque et un autre dans une autre bibliothèque. Ce sont physiquement deux livres différents, mais ils partagent la même donnée, sa “data”, comme son auteur, sa description ou les avis des utilisateurs …

• J’ai un deuxième contexte, “user”, qui gère l’ensemble des utilisateurs qui peuvent emprunter des livres dans la bibliothèque.

• Enfin, j’ai le contexte “library”, qui permet de modéliser les bibliothèques et leurs livres, physiquement. On pourra modifier l’état des livres de chaque bibliothèque (voir partie 1). Cet hexagone va utiliser les deux autres (“data” et “user”).

Implémentations

J’ai créé des modules pour chaque hexagone (“data-hexa”, “library-hexa” et “user-hexa”) et j’ai fait des modules qui les implémentent via le framework Spring (“data-hexa-impl-spring”, “library-hexa-impl-spring” et “user-hexa-impl-spring”). Ce découpage en module n’est pas obligatoire pour l’architecture hexagonale, mais cela permet de vérifier que chaque hexagone n’a aucune dépendance (tu peux vérifier avec leurs fichiers de configuration maven pom.xml).

D’un hexagone à un autre

Regardes la classe “LibraryBookOutputAdapter”. C’est un adaptateur de la porte de sortie “LibraryBookOutputPort”, afin de récupérer les données des bibliothèques pour l’hexagone “library”.

Mais c’est aussi un adaptateur des portes d’entrée “DataBookInputPort” de l’hexagone “data” et “UserInputPort” de l’hexagone “user”. Ainsi, les données récupérées des bibliothèques possèdent aussi les informations venant de ces deux autres hexagones.

Reste plus qu’à tester

Lance l’application via le runner “SpringApp”. Des que l’application est lancée, tu peux tester l’application via l’url “http://localhost:8080/takebook/index.html”.

Conclusion

J’espère que c’est clair pour toi. N’hésites pas à faire tes retours.

Photo libre de droit d’Ann Marie Ludlow provenant de Pexels.