Aller au contenu principal

Architecture Hexagonale

Préambule​

vasco-back doit respecter l'architecture hexagonale. Ce document explique comment cette architecture a été mise en place concrètement.

I. Documentation​

II. Organisation des packages​

Chaque module métier représente un hexagone qui sera organisé en packages de la façon suivante:

  • domain : le centre de l'hexagone, celui qui est en maitrise du métier; peut appeler le domain d'un autre module
  • application : partie user-side, assure les interactions entre l'extérieur et le domain
  • infrastructure : partie server-side, assure les interactions entre le domain et les éléments propres à l'infrastructure de l'application, comme par exemple la partie persistance en base de donnée
flowchart RL
	A[infrastructure] --> B[domain]
	B -->  C[user-side]

attention

Ne plus mettre les packages au pluriels sauf enums

1. User-Side : Package application​

  • controller :
    • appelle le domain.service (i.e. les services de son propre module)
    • transforme les objets du service en les objets attendus en entrée/sortie du controller par le biais des mappers
  • mapper
    • mapper des payloads depuis/vers les objets du domain
  • payload
    • objets en entrée/sortie du controller par rapport au user-side
    • les entrées doivent être suffixées par -Request
    • les sorties doivent être suffixées par -Response
    • les objets (et sous-objets) utilisés ne doivent pas appartenir à d'autres modules

2. Hexagon : Package domain​

attention

Cette couche ne manipule pas les objets user-side ni ceux de server-side. On s'autorise tout de même à utiliser les objets domain de tout autre module.

  • constant
  • enums
  • exception
  • mapper : seulement si besoin de mapper des objets de domain.model (depuis le même module ou par rapport à un autre module)
  • model :
    • les objets métiers (BO)
    • pas de suffixe, ils sont vraiment le coeur du métier
    • on essaye de spécialiser les objets et on évite d'avoir un objet couteau suisse
    • utilisation de l'héritage possible mais avec parcimonie
  • service
    • coeur du métier
    • appelé par la couche user-side
    • appelle la couche server-side par l'intermédiaire des SPI
    • appelle les services des domain externes
    • les paramètres des méthodes doivent éviter au maximum les types simple. Privilégier un objet regroupant les éléments nécessaires (ex: domain.model.ConventionCreation)
  • spi
    • Service Provider Interface
    • interfaces java qui doivent être implémentées par la couche server-side
    • permet l'inversion des dépendances
  • api
    • Application Provided Interface
    • interfaces java qui doivent être implémentées par la couche user-side
    • Non implémenté sur vasco, les controllers étant suffisamment simples. Cela correspond au SPI.

3. Server-side : Package infrastructure​

info

Pour anticiper des besoins potentiels, un premier package intermédiaire : infrastructure.persistence a été créé. Il correspond aux accès à la BDD par vasco. Potentiellement, infrastructure.external pourra être créé dans le cas d'appels à des services externes.

  • adapter
    • implémentation des SPI fournies par le domain
    • appelle la couche repository
    • transforme les objets du domain depuis/vers les -Entity
  • entity
    • objets persistés avec hibernate
    • suffixé par -Entity
  • mapper
    • mappers des entity depuis/vers les objets du domain
  • repository
    • interfaces JpaRepository