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

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

3.
#DevoxxFR
3
Le contexte du projet

4.
• 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

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.
Socle technique
• Actuator
• Data:
• AMQP

8.
Création d’un
nouveau
microservice

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
Infra AMQP
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
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

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 of templates »

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

16.
Définition du
"Domain Model"

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èle avec 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.
Implémentation
de la couche
« infrastructure »

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 scripts SQL ( DDL )
Bundle
(templates)
Model
(entities)
Templates pour
« PostgreSQL »
Entités du
microservice
Scripts
SQL
Changesets
Liquibase

26.
REST API
&
services de niveau
« application »

27.
Articulation REST - application

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

29.
REST API

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 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

32.
Pour conclure…

33.
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)

34.
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, …)

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 on rails »
DDD
+ =

39.
Merci !

40.
Annexes

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. 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

43.
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

44.
Architecture hexagonale