Mettre en place une architecture hexagonale, c'est un peu comme être une petite abeille qui construit sa ruche : si nos alvéoles ont cette forme d'hexagone régulier, c'est parce qu'elle permet de diviser l'espace en plusieurs cases pour chacune de nos larves, tout en minimisant la quantité de cire nécessaire à leur construction !
Dans notre analogie, la ruche représente notre application, les alvéoles sont comparables aux adaptateurs, et la cire symbolise les ports.
Mais que signifie tout ceci ? C'est ce que nous allons découvrir !
Qu'est-ce qu'un port ?
Un port est une interface qui peut être consommée par notre domaine ou exposée par celui-ci. Les ports constituent les canaux de liaisons entre les modules de notre application.
- On parle de port d'entrée lorsque le port constitue un point d'entrée d'utilisation de notre domaine. Ce sont donc des interfaces exposées et implémentées par notre domaine, mais utilisées par les modules externes à notre domaine.
- On parle de port de sortie lorsque le port constitue le moyen qu'a notre domaine d'utiliser les services de modules externes. Il s'agit donc d'interfaces déclarées et utilisées dans notre domaine, mais implémentées par les modules externes à celui-ci.
Qu'est-ce qu'un adapteur ?
Un adapteur constitue une classe externe à notre domaine qui va interagir avec le port. Cela peut signifier le consommer ou l'implémenter.
- Un adapteur primaire est une classe externe qui va consommer un port d'entrée. Il s'agit donc d'une classe qui va utiliser un service fourni par notre domaine. Il peut s'agir d'un contrôleur d'API par exemple, d'une console sous la forme d'un Main, ou de tout autre module qui aura besoin d'utiliser les services fournis par le modèle au moyen des ports d'entrée.
- Un adapteur secondaire est une classe externe qui va implémenter un port de sortie. Il s'agit donc d'une classe qui va fournir un service à notre domaine. Par exemple, cela peut être le module qui permet de communiquer avec la base de donnée
Qu'est ce que le domaine ?
Le domaine est le cœur de notre application. Il ne connait des implémentations concrète uniquement ce qu'il implémente lui-même et qui constitue toute la logique métier. Il ne possède aucune connaissance sur l'entité qui va consommer ses services, et ne possède aucune connaissance sur comment les services qu'il utilise sont implémentés. De ce fait il en est totalement indépendant.
Maintenant qu'on a vu toutes ces notions, vous vous demandez sans doute pourquoi mettre en place une telle architecture ? Pour le découvrir il vous suffit demandez à nos abeilles, par ici !
