Moins de câblage.
Plus de logique métier.
HexaGlue génère l'infrastructure, documente le domaine et bloque les régressions architecturales dans la CI. Votre équipe se concentre sur le code qui compte : la logique métier.
Le boilerplate et les régressions freinent l'équipe
Le code d'infrastructure est répétitif
Pour chaque agrégat, il faut écrire l'entité JPA, le repository Spring Data, le mapper, l'adapter. Ce code est mécanique : il suit les mêmes patterns, avec les mêmes erreurs possibles. Il représente parfois plus de la moitié du code total d'un projet.
Les régressions architecturales passent inaperçues
Un développeur pressé importe JPA dans le domaine. Un autre contourne un port pour appeler un repository directement. Ces raccourcis passent en revue parce qu'ils sont petits. Mais ils cassent l'isolation des couches et rendent le domaine difficile à tester.
La documentation est toujours en retard
Le wiki décrit l'architecture d'il y a 3 mois. Les nouveaux développeurs passent des jours à comprendre les agrégats, les ports et le câblage. Personne ne met à jour la documentation parce que tout le monde écrit du code.
Un outil qui s'intègre dans votre workflow existant
pom.xml, s'exécute à la compilation et produit du code, de la documentation et un rapport d'audit. Rien à changer dans votre workflow.| Votre défi | Ce que HexaGlue fournit |
|---|---|
| Code répétitif | Génération JPA : entités, repositories, mappers MapStruct et adapters de port générés automatiquement depuis le modèle de domaine. Dans l'étude de cas, 29 fichiers générés pour 8 agrégats |
| Régressions silencieuses | Audit en CI : les violations architecturales bloquent le build avec un message explicite. Le développeur sait immédiatement ce qui ne va pas et pourquoi |
| Documentation en retard | Living documentation : générée à chaque build depuis le code, elle liste les agrégats, entités, value objects, ports et leurs relations. Les nouveaux développeurs ont une cartographie à jour dès le premier jour |
HexaGlue s'exécute uniquement à la compilation. Il ne modifie pas le runtime, ne crée aucune dépendance transitive et ne change pas le comportement de l'application. Vous pouvez le retirer du pom.xml à tout moment : le code généré reste, le domaine n'est pas impacté.
5 minutes pour l'ajouter à votre projet
pom.xml, s'exécute à la compilation et produit du code, de la documentation et un rapport d'audit sans rien changer à votre workflow.1. Ajouter le plugin Maven
Une section <plugin> dans le pom.xml avec les dépendances des plugins souhaités (audit, living-doc, JPA). HexaGlue détecte automatiquement le domaine.
2. Compiler
mvn clean compile : HexaGlue classifie le domaine, génère l'infrastructure et produit la documentation. mvn verify : l'audit vérifie les règles d'architecture.
3. Intégrer en CI
Ajouter failOnError: true dans hexaglue.yaml pour bloquer les builds avec des violations critiques. Le rapport d'audit est disponible dans target/hexaglue/reports/.
# Configuration minimale pour démarrerclassification: exclude: - "com.acme.shop.config.*"
plugins: io.hexaglue.plugin.audit: failOnError: true # Bloque le build sur violation CRITICAL io.hexaglue.plugin.livingdoc: outputFormat: "markdown" io.hexaglue.plugin.jpa: generateRepositories: true generateAdapters: true
L'étude de cas e-commerce part d'un monolithe Spring Boot de 50 classes avec 10 anti-patterns. En 7 étapes, l'architecture passe de 13/100 à 63/100. Le code source est sur GitHub, chaque étape est reproductible.
Le câblage technique est automatisé.
Votre équipe se concentre sur le métier.
Voyez HexaGlue en action sur un projet réel ou ajoutez-le à votre build en 5 minutes.