Formalisez vos règles.
Vérifiez-les automatiquement.
HexaGlue transforme vos décisions d'architecture DDD et hexagonale en contraintes vérifiables à la compilation. Les écarts sont détectés dans la CI, pas lors de la prochaine revue manuelle.
Les règles existent, mais rien ne les applique
Les décisions d'architecture ne sont pas vérifiées
Vous définissez des règles : le domaine ne dépend pas de l'infrastructure, les ports sont des interfaces, les agrégats ont un identifiant typé. Ces règles sont documentées dans un ADR ou un wiki. Mais rien ne vérifie leur respect dans le code. Vous le découvrez en revue, quand le code est déjà écrit.
Les frontières hexagonales s'érodent
Un développeur ajoute un @Entity sur une classe de domaine. Un autre appelle un repository directement depuis un service applicatif. Chaque raccourci est petit, mais ils s'accumulent. En 6 mois, les couches sont percées et la migration vers le DDD stagne.
La traçabilité des classifications est absente
Quand une classe est classée comme agrégat ou value object, sur quel critère ? En revue manuelle, c'est une décision implicite. Si un nouveau développeur conteste le choix, il n'y a pas de trace de la justification.
Vos règles d'architecture deviennent du code
| Votre défi | Ce que HexaGlue fournit |
|---|---|
| Règles non vérifiées | Contraintes automatiques : ddd:entity-identity, ddd:domain-purity, hexagonal:layer-isolation, hexagonal:port-coverage, etc. Chaque violation est localisée (classe, package) et classée par sévérité |
| Frontières érodées | Audit à chaque build : l'audit s'exécute dans la CI avec un seuil configurable (failOnError). Un import JPA dans le domaine bloque le build immédiatement, pas dans 3 semaines |
| Traçabilité absente | Classification traçable : chaque type reçoit un rôle (agrégat, entité, VO, port...) avec la règle qui a déclenché la décision. Les conflits sont signalés explicitement avec des pistes de remédiation |
HexaGlue ne remplace pas vos décisions d'architecture : il les rend vérifiables. Vous définissez les règles (quelles conventions, quels seuils, quelles exclusions). HexaGlue les applique systématiquement à chaque build, sur l'ensemble du code.
De la règle à la vérification en 3 étapes
1. Vous définissez les conventions
Arborescence de packages, suffixes de noms, surcharges explicites dans hexaglue.yaml. HexaGlue classifie automatiquement à partir de ces conventions.
2. L'audit vérifie à chaque build
À chaque mvn verify, HexaGlue produit un rapport avec le score, les violations et l'inventaire architectural. En CI, le build échoue si une violation critique est détectée.
3. L'architecture évolue avec le code
La living documentation et le rapport d'audit reflètent l'état réel du code. Quand un développeur ajoute un agrégat ou modifie un port, la documentation et l'audit se mettent à jour automatiquement.
Dans l'étude de cas e-commerce, les 43 violations initiales ont été réduites à 7 en 6 étapes. Chaque étape montre la correction d'une catégorie de violations et l'impact sur le score. Le code source et les rapports sont disponibles sur GitHub.
Les règles existent déjà.
Rendez-les vérifiables à chaque build.
Voyez comment HexaGlue détecte les violations architecturales sur un projet réel ou commencez avec le tutoriel.