Monorepositorio con Java: organización del código y mejores prácticas

Introducción: qué es un monorepositorio y por qué es necesario en Java

En el mundo del desarrollo Java, existen dos enfoques principales para almacenar código: monorepositorio (monorepo) y multirrepositorio (multirepo). Un monorepositorio es una estrategia en la que todas las bases de código del proyecto (bibliotecas, servicios, utilidades, configuraciones) se almacenan en un único repositorio. Para los desarrolladores de Java que trabajan con grandes sistemas corporativos o microservicios, el monorepositorio se está convirtiendo en una solución cada vez más popular.

Las ventajas del monorepositorio en Java son evidentes:

• Versión única de dependencias: Todos los módulos utilizan una misma versión de las bibliotecas, lo que elimina conflictos (classpath hell).
• Refactorización simplificada: Un cambio de API en un módulo se ve inmediatamente en todos los módulos dependientes.
• Historial de cambios transversal: Un solo commit puede contener cambios en varios módulos, lo que facilita la depuración.
• Estandarización: Reglas unificadas de estilo de código, linting y CI/CD para todo el proyecto.

Sin embargo, un monorepositorio requiere una organización adecuada. En este artículo, analizaremos cómo estructurar correctamente un proyecto Java en un monorepositorio utilizando Maven y Gradle.

Parte principal: organización de un monorepositorio en Java

1. Estructura de directorios: enfoque modular

La base de un monorepositorio es la estructura modular. Cada módulo representa una unidad independiente (biblioteca, servicio, utilidad). Consideremos una estructura típica para un proyecto Java:

my-monorepo/├── build.gradle          # Archivo de compilación raíz (Gradle)├── settings.gradle       # Lista de módulos├── gradle.properties     # Configuraciones comunes├── gradle/│   └── wrapper/├── common/               # Bibliotecas comunes│   ├── common-utils/     # Utilidades (cadenas, fechas)│   └── common-dto/       # DTO para intercambio de datos├── services/             # Microservicios│   ├── user-service/     # Servicio de usuarios│   └── order-service/    # Servicio de pedidos├── libs/                 # Bibliotecas internas│   └── logging-lib/      # Biblioteca de logging├── tests/                # Pruebas de integración/extremo a extremo│   └── e2e-tests/└── buildSrc/             # Plugins y configuraciones comunes

Cada módulo internamente tiene la estructura estándar de Maven/Gradle:

user-service/├── build.gradle├── src/│   ├── main/│   │   ├── java/│   │   │   └── com/example/user/│   │   │       ├── controller/│   │   │       ├── service/│   │   │       └── repository/│   │   └── resources/│   │       └── application.yml│   └── test/│       └── java/└── Dockerfile

2. Gestión de dependencias: Maven BOM y Gradle Version Catalog

El principal problema de un monorepositorio es la sincronización de las versiones de las dependencias. En Java, esto se resuelve de dos maneras.

Opción 1: Maven BOM (Bill of Materials)

Se crea un POM raíz que declara todas las versiones de las dependencias. Los módulos hijos utilizan dependencyManagement:

<!-- pom.xml (raíz) --><dependencyManagement>    <dependencies>        <dependency>            <groupId>org.springframework.boot</groupId>            <artifactId>spring-boot-dependencies</artifactId>            <version>3.2.0</version>            <type>pom</type>            <scope>import</scope>        </dependency>        <dependency>            <groupId>com.example</groupId>            <artifactId>common-utils</artifactId>            <version>1.0.0</version>        </dependency>    </dependencies></dependencyManagement>

Opción 2: Gradle Version Catalog

En el archivo gradle/libs.versi