Cómo estructurar un proyecto Spring Boot aplicando Clean Architecture sin caer en sobre-ingeniería.
El problema con la estructura clásica
La mayoría de proyectos Spring Boot organizan el código por capa técnica: controllers/, services/, repositories/. Esto funciona al inicio, pero a medida que el proyecto crece, las dependencias se vuelven un espagueti y los services terminan con 2000 líneas.
Organización por dominio
En los microservicios de SAGCOM, cada servicio se organiza así:
src/main/java/com/previred/sagcom/ ├─ domain/ ← Entidades, Value Objects, Interfaces de repositorio ├─ application/ ← Casos de uso, DTOs, Mappers ├─ infrastructure/ ← Implementaciones JPA, Clients HTTP, Config └─ presentation/ ← Controllers REST, Request/Response
Regla de dependencia
La regla es simple: las dependencias apuntan hacia adentro. Domain no conoce nada externo. Application depende solo de domain. Infrastructure implementa las interfaces definidas en domain. Esta estructura hace que los tests unitarios sean triviales: mockeas las interfaces de domain y listo.
Pragmatismo sobre purismo
No necesitas crear 15 interfaces para una operación simple. Si un caso de uso es un CRUD básico, no lo compliques. Aplica Clean Architecture donde hay lógica de negocio compleja. Para el resto, un Service que usa un Repository directamente está bien.
Testing con esta estructura
La gran ventaja: puedes testear la lógica de negocio (domain + application) sin levantar Spring, sin base de datos, sin nada. Tests que corren en milisegundos. Los integration tests con Testcontainers quedan para infrastructure.
