Qu’est-ce qu’une architecture hexagonale (Alister Coburn 2005/2006) ? On a dessiné l'hexagone. Le coeur du système n’a pas de dépendances. On défini des ports (sortie db) et des adapters (api, console).
Ognon (Jefrey palermo - 2009) : les dépendances ne se font que de l’extérieur vers l’intérieur. Là aussi on a fait un schéma. Isoler le centre de l’architecture, le business vs ihm, persistence, apis Le liant étant l’injection de dépendance
- testable
- isolation du stockage
- ddd friendly
- décommissionnement des legacy
- l’architecture est partagée, l’archi est un rôle qui peut être endossée par tous
- complexité supplémentaire
- Favorise le cycle itératif.
- Favorise les choix d’architecture tardifs.
- Favorise les changements de techno.
- Favorise une couche métier « pure »
Si on focalise tout sur le modèle de persistance, cela conduit à un modèle anémique.
- ne pas mettre des interfaces partout, simplifier de manière pragmatique
- encourage l'injection de dépendance donc permet de modulariser son produit avec des implémentations différentes
- Event storming sur un projet d'affichage des trains SNCF : c'était le testeur qui avait le plus de connaissance métier. Il y avait un trou fonctionnel énorme au milieu du projet.
- Que se passe-t-il si le core Domain change ?
- Comment garantir le bon respect de l’archi dans le temps ? en .NET : Roselyn, outil de diagramme / en java : ArchUnit.
Comment on impose/convainc ce genre d’architecture ? Opposition entre le bridage et la pédagogie ? Mob programming !
Uncle Bob a proposé en 2012 la Clean architecture.