Génération JPA

La persistance est du glue code.
Pas besoin de l'écrire.

HexaGlue génère les entités JPA, repositories Spring Data, mappers MapStruct et adapters de ports depuis votre modèle de domaine. Zéro code manuel pour la couche persistance.

Artefacts générés

5 types d'artefacts, synchronisés à chaque build

À partir de votre modèle de domaine pur (sans annotations JPA), HexaGlue produit toute la couche persistance. Dans l'étude de cas e-commerce, cela représente 29 fichiers générés automatiquement.

Artefact	Quantité typique	Rôle
Entités JPA	1 par agrégat	Classes annotées `@Entity`, `@Table`, `@Column`, prêtes pour Hibernate
Embeddables	1 par Value Object persisté	`@Embeddable` pour les VO stockés en colonnes (ex: `MoneyEmbeddable`)
Repositories Spring Data	1 par agrégat	Interfaces `extends JpaRepository<T, ID>`
Mappers MapStruct	2 par agrégat (interface + impl)	Conversion bidirectionnelle domaine ↔ JPA
Adapters de port	1 par driven port Repository	Implémente le port défini dans le domaine, wrappe le repository Spring Data

Le nombre d'artefacts générés croît linéairement avec la taille du domaine. Pour un domaine de 8 agrégats (étude de cas e-commerce), HexaGlue produit 29 fichiers. Pour un domaine de 20 agrégats, attendez environ 70 fichiers. C'est du code que vous n'avez pas à écrire ni à maintenir.

Mapping

Comment le domaine se transforme en JPA

HexaGlue analyse la classification de chaque type et applique des règles de transformation déterministes. Le tableau ci-dessous montre la correspondance entre les concepts du domaine et les artefacts JPA générés.

Concept domaine	Transformation	Exemple
Aggregate Root	`@Entity` + `@Table` + Repository + Mapper + Adapter	`Order` → `OrderEntity`, `OrderJpaRepository`, `OrderMapper`, `OrderAdapter`
Entity (enfant)	`@Entity` lié à l'agrégat parent via `@JoinColumn`	`OrderLine` → `OrderLineEntity`
Value Object (multi-champs)	`@Embeddable` avec tous les champs mappés	`Money(amount, currency)` → `MoneyEmbeddable`
Value Object (mono-champ)	Déplié vers le type primitif, pas d'embeddable	`record Quantity(int value)` → colonne `int`
Identifier	Déplié vers le type wrappé pour `@Id`	`OrderId(UUID)` → `@Id UUID id`
Driven Port (Repository)	Interface `JpaRepository` + classe Adapter qui implémente le port	`OrderRepository` → `OrderJpaRepository` + `OrderAdapter`

Ces règles sont déterministes : pour un même modèle de domaine, HexaGlue produit toujours le même code JPA. Pas de magie, pas de convention cachée. La classification du type détermine entièrement ce qui est généré.

Comparaison

Votre code vs le code généré

Vous écrivez le domaine. HexaGlue génère l'infrastructure. Les deux sont synchronisés par construction.

// Pas d'annotation JPA, pas d'import infrastructure
public class Order {
    private OrderId id;
    private CustomerId customerId;
    private List<OrderLine> lines;
    private Money total;
    private OrderStatus status;

    public void addLine(Product product, int quantity) {
        // Logique métier uniquement
    }
}

@Entity
@Table(name = "orders")
public class OrderJpaEntity {
    @Id @GeneratedValue
    private Long id;

    @Column(name = "customer_id")
    private Long customerId;

    @OneToMany @JoinColumn(name = "order_id")
    private List<OrderLineJpaEntity> lines;

    @Embedded
    private MoneyEmbeddable total;

    @Enumerated(EnumType.STRING)
    private OrderStatus status;
}

Capture d'écran du code JPA généré par HexaGlue à partir du modèle de domaine

Ownership

Du code généré qui vous appartient

Le code produit par HexaGlue n'est pas une boîte noire. Ce sont des classes Java standard, lisibles, débuggables. Vous choisissez comment les intégrer à votre projet.

Régénérer à chaque build

Mode par défaut. Les artefacts sont écrits dans target/ et régénérés à chaque mvn compile. Le code généré n'est pas versionné : il reste toujours synchronisé avec le domaine.

Committer dans votre code

Redirigez la sortie vers src/main/java via l'option outputDirectory. Le code généré devient partie intégrante de votre projet. Vous pouvez ensuite le modifier, l'enrichir ou désactiver la régénération.

Sur l'étude de cas e-commerce (8 agrégats), le plugin génère 29 fichiers de persistance. C'est du code que vous n'écrivez pas, que vous ne maintenez pas, et qui reste synchronisé avec votre domaine par construction.

Performance

Génération JPA vs SQL optimisé : un faux dilemme

Une objection fréquente : le SQL écrit à la main est plus performant que le code JPA généré. C'est vrai. Mais les deux approches ne répondent pas au même problème.

HexaGlue optimise le coût humain

Moins de code à écrire, moins de code à maintenir, moins de bugs de câblage. Pour la grande majorité des applications métier (CRUD, back-office, SaaS, SI internes), les performances JPA standard sont largement suffisantes.

Le SQL manuel optimise le coût machine

Requêtes taillées pour le plan d'exécution, exploitation fine des index, contrôle total sur les jointures. Indispensable pour les chemins critiques à forte charge (trading, analytics, temps réel).

Les deux approches coexistent dans les architectures matures. HexaGlue couvre les 80 à 90 % de cas CRUD standard où la productivité prime sur la micro-optimisation.
Pour les requêtes critiques, Spring Data JPA offre @Query (JPQL), requêtes natives et projections : vous gardez le contrôle là où il compte, sans renoncer à l'automatisation partout ailleurs.

Besoin d'une génération sur mesure ?

Ce plugin démontre qu'il est possible de générer automatiquement toute la couche de persistance depuis le modèle de domaine. Bien qu'il couvre les patterns les plus courants, il ne prétend pas répondre à toutes les conventions et exigences de chaque entreprise.

Plugins sur mesure Services Nous contacter

Votre métier mérite toute votre attention.
Générez la persistance au build.

Voyez comment HexaGlue produit 29 fichiers de persistance à partir d'un domaine pur.

Voir la génération en action Configurer le plugin JPA

La persistance est du glue code.Pas besoin de l'écrire.