Spring Boot
Desarrollo de servicios backend y APIs con Spring Boot y Spring Framework para aplicaciones empresariales.
Pedir diagnóstico gratuitoEl reto
Spring Boot permite construir servicios backend orientados a aplicaciones modernas. El desarrollo debe adaptarse a las necesidades reales del proyecto, su arquitectura y los sistemas con los que necesita integrarse.
No siempre hay que empezar de cero: en muchos casos lo razonable es levantar los servicios nuevos en Spring Boot y dejar que convivan con la aplicación existente mientras se decide qué se migra y en qué orden.
Tecnologías
La mayoría de proyectos no empiezan en blanco: empiezan al lado de algo que ya funciona y no se puede parar.
El planteamiento habitual no es migrar la aplicación entera, sino levantar los servicios nuevos en Spring Boot y dejar que convivan con lo anterior. Eso permite entregar valor desde la primera semana sin poner en riesgo lo que ya está en producción, y deja la decisión de qué se mueve para cuando haya datos en lugar de intuiciones.
Lo que hace que esa convivencia funcione no es el framework, son las fronteras: quién llama a quién, con qué contrato y qué pasa si una de las dos partes cambia. Cuando esas fronteras no existen, acaban siendo dos sistemas acoplados por la base de datos, que es lo peor de las dos opciones. Por eso el trabajo de diseño de las APIs va por delante del de infraestructura.
Spring Boot aporta aquí algo concreto: arranque autónomo, configuración por entorno y un modelo de pruebas que permite levantar el contexto real de la aplicación. Eso último es lo que más cambia el día a día de un equipo, porque convierte las pruebas de integración en algo que se ejecuta en cada cambio y no una vez al mes.
El orden importa: la observabilidad y las pruebas se montan al principio, cuando cuestan poco, no al final, cuando ya hay algo que arreglar y ninguna forma de ver qué pasa.
Son baratas al principio y caras después. Conviene tomarlas de forma consciente, no por defecto.
| Decisión | Opciones | Criterio |
|---|---|---|
| Estructura del proyecto | Módulo único o varios módulos | Único mientras el equipo sea uno: varios módulos añaden fricción de construcción antes de aportar aislamiento |
| Acceso a datos | Spring Data JPA o SQL explícito | JPA para el ciclo de vida de entidades; SQL explícito para informes y consultas complejas, donde el mapeo estorba |
| Esquema de base de datos | Generado por Hibernate o versionado con migraciones | Migraciones versionadas siempre que haya producción: generar el esquema al arrancar impide saber en qué estado está cada entorno |
| Pruebas de integración | Base de datos en memoria o contenedor con la real | La real: una base de datos en memoria no reproduce el dialecto ni el comportamiento transaccional, y los fallos aparecen en producción |
| Configuración | Ficheros por perfil o variables de entorno | Variables de entorno para lo que cambia entre entornos y para todo lo que sea secreto |
Para un desarrollo nuevo, la versión con soporte más reciente. Para un proyecto que ya existe, la decisión depende de la versión de Java: Spring Boot 3 exige Java 17 como mínimo y arrastra el cambio de javax a jakarta en toda la aplicación.
Eso convierte el salto en un proyecto con entidad propia, no en una actualización de dependencia. Cuando hay una aplicación en Spring Boot 2 que hay que mover, el camino y el orden están explicados en la página sobre la migración hacia Spring Boot.
Ninguno es un fallo del framework: son comportamientos que sorprenden si no se conocen de antemano.
Un método transaccional que no abre transacciónCausa: La llamada viene de otro método de la misma clase. El proxy que aplica @Transactional solo intercepta las llamadas que entran desde fuera del bean.
Qué se hace: Mover el método a otro componente, para que la llamada atraviese el proxy. Es donde más tiempo se pierde depurando, porque el código parece correcto.
La suite de pruebas tarda minutos en arrancarCausa: Cada clase de prueba levanta un contexto distinto, porque cambian las anotaciones o la configuración y Spring no puede reutilizar el que tenía en memoria.
Qué se hace: Unificar la configuración de las pruebas de integración para que compartan contexto. Reducir el número de contextos distintos suele dividir el tiempo total entre tres o cuatro.
Una propiedad de configuración que se ignora en silencioCausa: La clave está mal escrita o pertenece a un perfil que no está activo. No hay error: se aplica el valor por defecto y el servicio arranca.
Qué se hace: Validar la configuración en el arranque, de forma que un valor obligatorio que falte impida levantar el servicio en lugar de dejarlo en pie con datos incorrectos.
Se agotan las conexiones del pool bajo cargaCausa: Hay transacciones abiertas mientras se espera a un sistema externo, o el tamaño del pool se quedó en el valor por defecto sin medir nada.
Qué se hace: Sacar las llamadas externas fuera de la transacción y dimensionar el pool a partir de la concurrencia real. Subir el número sin entender la causa solo retrasa el problema.
Preguntas frecuentes
No. Lo habitual es levantar los servicios nuevos en Spring Boot y dejar que convivan con la aplicación existente. La migración del resto, si tiene sentido, se decide después y con datos.
No. Un monolito modular, bien probado y desplegable es una arquitectura legítima, y para muchas aplicaciones empresariales es la correcta. Trocear un sistema que nadie entiende del todo suele multiplicar el problema en lugar de resolverlo.
Spring Boot 3 requiere Java 17 como mínimo. Si la aplicación está en Java 8 u 11, la subida de versión se aborda antes y como trabajo independiente, para no mezclar dos fuentes de fallos distintas.
Lo habitual es trabajar contra vuestro repositorio con las mismas reglas que el resto del equipo, para que cada entrega pase por vuestra revisión y llegue a producción por el camino de siempre.
Incluye el empaquetado y que el despliegue sea reproducible. La administración de sistemas y la infraestructura no: si vuestro proyecto lo necesita, os lo digo en la primera llamada en lugar de aprenderlo sobre la marcha.
JavaEvolve
Dime qué sistemas tiene que tocar y con qué convive. Con eso se puede plantear si conviene convivencia o migración.
Pedir diagnóstico gratuitoLlamada de 30 minutos, sin coste. Respondo en menos de 48 horas.
En la llamada: versión de Java, framework, servidor y qué duele hoy. Si no puedo ayudarte, te lo digo. Qué incluye el diagnóstico