Monorepo avec Java : organisation du code en pratique

Introduction : pourquoi un monorepo dans les projets Java ?

Avec la complexité croissante des applications Java, les équipes sont souvent confrontées à un dilemme : stocker tout le code dans un seul dépôt (monorepo) ou le diviser en plusieurs dépôts de microservices (polyrepo). La pratique montre que le monorepo est particulièrement efficace pour les projets partageant une logique métier, des bibliothèques et des configurations communes. En Java, il permet de gérer centralement les dépendances, les versions et les builds, simplifiant le refactoring et l'intégration.

Dans cet article, nous allons voir comment organiser le code Java dans un monorepo en pratique : de la structure des dossiers à la configuration du CI/CD. Vous apprendrez à éviter les erreurs typiques et à accélérer le développement.

1. Structure du monorepo pour Java

Le principe clé du monorepo est la modularité. En Java, cela se réalise via des projets multimodules (multi-module project). Chaque module est responsable de son propre domaine : bibliothèques communes, services, utilitaires.

Exemple de structure typique :

my-java-monorepo/├── build.gradle          # Fichier de build racine├── settings.gradle       # Inclut tous les modules├── gradle.properties     # Versions communes des dépendances├── common-lib/           # Bibliothèque commune (DTO, utilitaires)│   ├── build.gradle│   └── src/├── service-auth/         # Service d'authentification│   ├── build.gradle│   └── src/├── service-payment/      # Service de paiement│   ├── build.gradle│   └── src/└── integration-tests/    # Tests d'intégration    ├── build.gradle    └── src/

Pour la gestion des versions, il est pratique de placer les dépendances communes dans le fichier racine build.gradle ou pom.xml (pour Maven). Dans Gradle, cela se fait via le bloc subprojects :

subprojects {    apply plugin: 'java'    group = 'com.pythonlib'    version = '1.0.0'

    repositories {        mavenCentral()    }

    dependencies {        testImplementation 'org.junit.jupiter:junit-jupiter:5.10.0'    }}

Une telle structure permet d'ajouter facilement de nouveaux services sans copier les configurations, et garantit que tous les modules utilisent les mêmes versions de bibliothèques.

2. Gestion des dépendances et des versions

L'un des principaux problèmes du monorepo est le conflit de versions. En Java, pour le résoudre, on utilise BOM (Bill of Materials) ou une description centralisée des dépendances. Prenons un exemple avec Gradle utilisant java-platform.

Créons un module platform qui définit toutes les dépendances externes :

// platform/build.gradleplugins {    id 'java-platform'}

javaPlatform {    allowDependencies()}

dependencies {    constraints {        api 'com.fasterxml.jackson.core:jackson-databind:2.15.2'        api 'org.springframework.boot:spring-boot-starter-web:3.1.5'        api 'org.slf4j:slf4j-api:2.0.9'    }}

Maintenant, dans chaque service, on peut simplement référencer la plateforme :

// service-auth/build.gradledependencies {    implementation platform(project(':platform'))    implementation 'com.fasterxml.jackson.core:jackson-databind'    implementation 'org.springframework.boot:spring-boot-starter-web'}

Cela garantit que tous les modules utilisent les mêmes versions. Lors de la mise à jour d'une version dans platform, les modifications s'appliquent automatiquement à tous les services.

Conseil : pour Maven, utilisez <dependencyManagement> dans le pom.xml racine. Cela fonctionne de manière similaire.

3. CI/CD pour le monorepo

L'organisation de l'intégration continue dans un monorepo nécessite une approche particulière. On ne peut pas builder tous les modules à chaque commit – cela ralentirait le pipeline. La solution optimale est le build incrémental basé sur les modifications.

Exemple avec GitHub Actions utilisant paths :

name: Java CIon: