#DevoxxFR Microservices, DDD et bootstrapping pour faire un départ lancé… Laurent Guérin Aurélien Brisard 1 OneCraft

Qui parle ? Laurent Guérin Aurélien Brisard Senior Architect Architect & DevOps expert Software Crafter DDD supporter @ltguerin Telosys creator OneCraft

#DevoxxFR 3 Le contexte du projet

• Client: secteur public • Organisation: itératif, ~130 développeurs • Legacy: • Important de ~17 années, ~100 modules • Architecture: 3-tier monolithique Java • Modernisation: • Débutée en 2021, ~20 microservices • Architecture: 3-tier microservice Legacy Cloud Cloud – IA Contexte du projet

Contexte du projet Cloud Cloud – IA Legacy Infrastructure: Cloud Système d’exploitation Orchestration de conteneurs: Kubernetes Moteur de conteneurs: Containerd Service Mesh: Istio Microservice: Spring-boot Microservice: Spring-boot Microservice: Spring-boot Base de données: PostgreSQL Appli mobile: Xamarin SPA: Vue.js Batch: Spring batch Batch: Spring batch

• Pattern principal – Domain Driven Design (DDD): • 3 couches DDD « classiques » • 1 domaine = 1 microservice • Approche: « contract first » Structure des microservices « standards »

Socle technique • Actuator • Data: • AMQP

Création d’un nouveau microservice

Projet microservice Framework « léger » ( fonctionnalités techniques, librairies communes, configuration des plugins de compilation/packaging) Structuration Maven

Modules Maven Parent Domain Infra SQL Infra AMQP Application DTO Microservice etc... Tout ça pour chaque microservice ? Comment bien démarrer ? => Copier/Coller ? => Bootstraping ? REST API

Génération de code… ? Black box Model Résultat imposé !  Fichiers générés Objections classiques : • C’est lourd • Le code généré n’est pas propre ou non conforme aux attentes • Souvent intrusif : le générateur impose des choix (style de code, framework, etc )

Génération de code Templates Model Personnalisation du projet, du modèle et des templates Résultat = exactement ce qu’on veut ☺ Black box Fichiers générés Model Résultat imposé !  Fichiers générés Conf projet

Langage de templating : VTL ( Velocity Template Language ) • Directives : #set, #if, #foreach, … • Commentaires : ##, #* … *# • Variables & objets du modèle : $xxx, $xxx.yy, $xxx.method() • Classes Java spécifiques (si besoin) Templates Telosys http://velocity.apache.org/ /** * REST DTO for entity "${entity.name}" * * @author ${AUTHOR} * */ public class ${entity.name}RestDto { #foreach($attribute in $entity.attributes) private $attribute.type $attribute.name; #end

« Bundle of templates »

Initialisation de la structure du projet 1 Bundle (templates) No model Config projet

Définition du "Domain Model"

Modèle DDD – Exemple : 1 Clé primaire composite

Modèle Telosys 1 Une entité est décrite à l’aide d’un DSL (Domain-Specific Language) Grammaire très simple et extensible avec des « tags » DSL #tag 1 modèle = 1 répertoire Modèle « léger » basé sur des fichiers « texte » (pas d’UML) 1 entité = 1 fichier texte ( « .entity » )

@AggregateRoot @DbTable(T_ORDER) #MyEntityTag Order { // Id ( Primary Key ) num : int { @Id @NotNull @Label("order number") } ; orderDate : date { @NotNull @Label("order date")} ; status : short { @NotNull @DefaultValue(0) #MyTag(xy) }; comment : string { @Size(120) } ; // FK referencing Customer customerId : int { @FK(Customer) } ; // Links items : OrderItem[] ; // Many deliveryAddress : DeliveryAddress ; // One // No link to Customer (not in the aggregate, just FK) } Attributs - Primary Key - Basic attrib. - Foreign Key Liens - to one - to many @xxx Annotations Composite PK & FK Fichier « .entity » Types neutres Entité #xxx Tags

Visualisation du modèle avec PlantUML Bundle (templates) Model (entities) Templates pour PlantUML Entités du microservice Fichier « .plantuml »

Génération du module « domain » Bundle (templates) Model (entities) Templates dédiés au « domain » Entités du microservice 

Implémentation de la couche « infrastructure »

DDD : « infrastructure » Domain layer Infrastructure layer « Port » << interface >> Repository Application layer xxx xxx Clés composites => changement d’implémentation en cours de projet : Spring Data JDBC → JPA → MyBatis Repository implementation ( MyBatis )

Génération du module « infra-mybatis » Bundle (templates) Model (entities) Templates dédiés à « mybatis » Entités du microservice  

Génération des scripts SQL ( DDL ) Bundle (templates) Model (entities) Templates pour « PostgreSQL » Entités du microservice Scripts SQL Changesets Liquibase

REST API & services de niveau « application »

Articulation REST - application

Génération : DTO + application + REST Bundle (templates) Model (entities) Templates rest-dto rest-app Entités du microservice   factory 

REST API

REST API « Contract First » « Code First » « Contract First » Contract ( Open API) Il va falloir gérer 2 modèles ( Telosys + Open API ) ? Contract ( Open API) Code Code

Génération des fichiers OpenAPI Bundle (templates) Model Telosys (entities) Templates pour générer une spec Open API Meta-model “Telosys” Meta-model “Open API” M2M DTO & interfaces Contract ( Open API) Code « Model to Model » .yaml

Pour conclure…

Ce qu’on ne vous a pas montré… • Adaptation spécifique au framework du projet • Génération des tests unitaires (JUnit, …) • Génération des tests d’intégration (Postman, SOAPUI, …) • Bootstrapping des batchs (Spring Batch) • Bootstrapping des IHM (CRUD)

Les gains • Productivité démarrage rapide, réduction de la charge de travail & réduction des délais • Simplification certaines parties du code peuvent être générées intégralement et deviennent « invisibles » pour le développeur (DTO, mappers, …) • Standardisation respect des règles de développement dans les templates • Qualité application des bonnes pratiques dans les templates (Clean Code, Software Craftsmanship, tests unitaires, …)

Jusqu’ou aller ? • Trouver un équilibre • Privilégier les « quick wins » • Savoir s’arrêter Temps investi dans les templates Temps de développement gagné (+qualité)

Générateur de code : critères de choix

Flexibilité & adaptabilité • Capacité à générer tout type de code (langages, frameworks, autres modèles) => un seul outil pour tout générer • Le projet décide de ses choix et le générateur s’adapte - adaptation au socle du projet (ex : MyBatis, Spring Boot + JAX-RS) - adaptation au framework du projet (héritage, pom parents, etc) - respect des conventions et standards de développement du projet • Le modèle doit être extensible (ex : les #tags) • Les templates doivent être facilement adaptables • Possibilité de gérer les clés primaires composites

« DDD on rails » DDD + =

Merci !

Annexes

@telosys tag "telosys" groups/1340197/ channel "Telosys" https://www.telosys.org/ • Telosys CLI : https://github.com/telosys-tools-bricks/telosys-cli • Telosys Eclipse plugin : https://github.com/telosys-eclipse-v3/TelosysToolsPlugin All stars are welcome ;-) Stay tuned !

Spring-Data-JDBC vs. MyBatis vs. Implémentation JPA Spring-Data-JDBC MyBatis Impl. JPA Framework de persistance de type ORM X X Indépendance du code avec le SGBD X X Gestion des relations dans le modèle objet (aggregat) X X Ecriture des requêtes avec le language natif du SGBD X X X Gestion des clés composées X X Chargement différé des relations (ex: lazy loading) X X Cache de niveau 2 X X Gestion des procédures stockées X X X Gestion des géométries X X X

Processus & Pipeline CI/CD • Processus commun: • GitLab flow (feature + release branching) • Merge request obligatoires • Pipeline CI/CD standardisés: • Expérience développeur intégrée en faisant de GitLab l’outil central • Templates GitLab-CI

Architecture hexagonale