#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

Microservices-DDD-Telosys-Devoxx-FR-2022

  • 1.
    #DevoxxFR Microservices, DDD et bootstrapping pourfaire un départ lancé… Laurent Guérin Aurélien Brisard 1 OneCraft
  • 2.
    Qui parle ? LaurentGuérin Aurélien Brisard Senior Architect Architect & DevOps expert Software Crafter DDD supporter @ltguerin Telosys creator OneCraft
  • 3.
  • 4.
    • Client: secteurpublic • 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
  • 5.
    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
  • 6.
    • Pattern principal– Domain Driven Design (DDD): • 3 couches DDD « classiques » • 1 domaine = 1 microservice • Approche: « contract first » Structure des microservices « standards »
  • 7.
  • 8.
  • 9.
    Projet microservice Framework« léger » ( fonctionnalités techniques, librairies communes, configuration des plugins de compilation/packaging) Structuration Maven
  • 10.
    Modules Maven Parent Domain Infra SQL InfraAMQP Application DTO Microservice etc... Tout ça pour chaque microservice ? Comment bien démarrer ? => Copier/Coller ? => Bootstraping ? REST API
  • 11.
    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 )
  • 12.
    Génération de code Templates Model Personnalisation duprojet, 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
  • 13.
    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
  • 14.
    « Bundle oftemplates »
  • 15.
    Initialisation de lastructure du projet 1 Bundle (templates) No model Config projet
  • 16.
  • 17.
    Modèle DDD –Exemple : 1 Clé primaire composite
  • 18.
    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 » )
  • 19.
    @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
  • 20.
    Visualisation du modèleavec PlantUML Bundle (templates) Model (entities) Templates pour PlantUML Entités du microservice Fichier « .plantuml »
  • 21.
    Génération du module« domain » Bundle (templates) Model (entities) Templates dédiés au « domain » Entités du microservice 
  • 22.
  • 23.
    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 )
  • 24.
    Génération du module« infra-mybatis » Bundle (templates) Model (entities) Templates dédiés à « mybatis » Entités du microservice  
  • 25.
    Génération des scriptsSQL ( DDL ) Bundle (templates) Model (entities) Templates pour « PostgreSQL » Entités du microservice Scripts SQL Changesets Liquibase
  • 26.
    REST API & services deniveau « application »
  • 27.
  • 28.
    Génération : DTO+ application + REST Bundle (templates) Model (entities) Templates rest-dto rest-app Entités du microservice   factory 
  • 29.
  • 30.
    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
  • 31.
    Génération des fichiersOpenAPI 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
  • 32.
  • 33.
    Ce qu’on nevous 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)
  • 34.
    Les gains • Productivité démarragerapide, 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, …)
  • 35.
    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é)
  • 36.
    Générateur de code: critères de choix
  • 37.
    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
  • 38.
    « DDD onrails » DDD + =
  • 39.
  • 40.
  • 41.
    @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 !
  • 42.
    Spring-Data-JDBC vs. MyBatisvs. 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
  • 43.
    Processus & PipelineCI/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
  • 44.