Esta es la única lección del curso que no habla de CicloUrbana, y es deliberado. La red de Ribalta está construida, probada, desplegada, observada y revisada; lo que queda no es una pieza más del proyecto, sino la capacidad de seguir aprendiendo cuando ya no haya un temario que seguir.

Y eso tiene su propia técnica. Internet está lleno de material sobre Spring Boot, y buena parte está desactualizado de una forma especialmente traicionera: un tutorial de Spring Boot 2 no parece antiguo —el código compila casi igual— pero enseña javax.persistence en lugar de jakarta.persistence, WebSecurityConfigurerAdapter en lugar de SecurityFilterChain y Spring Cloud Sleuth en lugar de Micrometer Tracing. Saber distinguirlo vale más que cualquier lista de enlaces.

Esta lección organiza los recursos que sí merecen tu tiempo, comentados y con criterio: qué documentación leer y cómo, por qué el código fuente es la mejor fuente, cómo mantenerse al día y planificar una actualización de versión mayor, qué libros valen la pena y para quién, dónde está la comunidad, cómo practicar de verdad, qué temas son el siguiente paso natural desde donde estás ahora, y una hoja de ruta razonada para los próximos seis meses.

1. Aprender con criterio
2. La documentación oficial y cómo leerla
3. El código fuente como documentación
4. Mantenerse al día
5. Planificar una actualización de versión mayor
6. El ecosistema Java
7. Libros
8. Certificaciones
9. Comunidad
10. Práctica deliberada
11. Temas naturales para el siguiente paso
12. Cómo evaluar un recurso
13. Una hoja de ruta de seis meses
14. Errores Comunes y Consejos
15. Ejercicios

Un aviso antes de la lista, porque es lo que decide si el resto sirve de algo.

El cuello de botella no es el acceso a la información: es la atención. Hay más contenido sobre Spring Boot del que se puede consumir en una vida, y el impulso natural —guardar veinte enlaces, apuntarse a tres boletines, empezar cuatro cursos— produce la sensación de estar aprendiendo sin que se consolide nada. La forma que sí funciona tiene tres rasgos:

Y una jerarquía de fuentes que conviene interiorizar, de más a menos fiable: el código fuente > la documentación de referencia > las guías oficiales > los libros de autores reconocidos > las conferencias > los artículos de blog > las respuestas de foros > el contenido generado sin revisión. No significa empezar siempre por arriba: significa que cuando dos fuentes se contradicen, gana la de arriba.

Cómo leer la documentación de referencia sin perderse. Tres tácticas que cambian la experiencia:

• Búscala, no la leas de arriba abajo. Está escrita para consultarse. La estructura de secciones y el buscador integrado están pensados para llegar directamente al párrafo que responde a tu pregunta.
• Empieza por el apéndice de propiedades. Cuando dudes de si algo es configurable, la respuesta suele estar ahí, con el valor por defecto —que es la mitad de la información útil—.
• Lee las notas de versión de la versión que usas. Es media hora bien invertida: te enteras de funcionalidades que llevas meses reimplementando a mano.

Cómo leer javadoc con provecho. No es documentación de marketing: es el contrato. Lo que hay que buscar en él son las tres cosas que la firma no dice: qué ocurre en los casos límite (¿devuelve null o lista vacía?, ¿acepta cero?), qué excepciones lanza y cuándo, y si es seguro entre hilos. Ese último dato aparece con frecuencia en una frase del javadoc de clase y es exactamente el que se busca cuando algo falla bajo carga.

Un ejemplo concreto de recorrido, porque la técnica se entiende mejor en acción. Supón que quieres saber si puedes limitar el tamaño de la cola del ejecutor asíncrono y qué pasa cuando se llena:

Cuatro consultas, cinco minutos, y una respuesta que no depende de que ningún artículo la haya contado bien.

Aquí está el consejo con mejor relación esfuerzo/beneficio de toda la lección: léete el código de Spring. Es abierto, está en GitHub, está razonablemente comentado y responde preguntas que ninguna documentación responde.

Por qué es la mejor fuente. La documentación describe la intención; el código describe el comportamiento. Cuando algo no funciona como esperabas, la diferencia entre ambos es exactamente donde está tu problema. Y a diferencia de un artículo, el código nunca está desactualizado respecto a sí mismo.

Tres cosas que conviene aprender a leer:

Las clases de autoconfiguración. Buscar *AutoConfiguration en el árbol de spring-boot-autoconfigure y leer una entera —DataSourceAutoConfiguration, JacksonAutoConfiguration o WebMvcAutoConfiguration— desmonta la sensación de magia de golpe. Se ve qué condiciones (@ConditionalOnClass, @ConditionalOnMissingBean) activan cada bean, y por tanto qué tienes que hacer para sustituirlo: casi siempre, declarar el tuyo.

Las clases *Properties. ServerProperties, JpaProperties o DataSourceProperties son la lista exacta y tipada de lo que se puede configurar, con sus valores por defecto en los campos. Suele ser más rápido que buscar en la documentación.

Los spring.factories y AutoConfiguration.imports. El fichero META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports es literalmente la lista de todo lo que Spring Boot puede autoconfigurar. Leerla una vez da una idea del alcance del framework que ninguna otra cosa da.

Con las fuentes descargadas, Ctrl+B sobre cualquier anotación en el IDE lleva a su definición. Ese es el hábito: cuando no entiendas por qué algo se comporta así, entra.

Spring Boot publica una versión menor cada seis meses (noviembre y mayo, aproximadamente) y correcciones cada mes. Lo importante no es el calendario, sino la política de soporte:

La consecuencia práctica es dura y conviene asumirla: una aplicación en producción necesita subir de versión menor al menos una vez al año. No es una mejora opcional, es mantenimiento de seguridad. Un proyecto que lleva tres años en la misma versión menor no está «estable»: está acumulando vulnerabilidades conocidas sin parche.

La estrategia sana es subir pronto y a menudo: pasar de 3.3 a 3.4 en cuanto sale y hay tiempo es un trabajo de horas; pasar de 2.7 a 3.x con cuatro años de retraso es un proyecto de semanas.

La última fila no es negociable: una vulnerabilidad conocida en un framework tan extendido se explota masivamente a las pocas horas de publicarse.

Cómo leer unas notas de versión en diez minutos. Tienen siempre la misma estructura y conviene recorrerla en este orden: primero «Breaking Changes», que es lo único que puede romperte y suele ocupar media pantalla; después «Deprecations», para saber qué tienes que empezar a cambiar aunque hoy siga funcionando; luego «Dependency Upgrades», donde se ve qué versiones de Hibernate, Jackson o Tomcat vienen dentro —y si alguna te afecta directamente—; y por último «New and Noteworthy», que es la parte divertida y la menos urgente. Leerlas al revés, empezando por las novedades, es el motivo por el que mucha gente se lleva sorpresas.

Subir de una versión mayor a la siguiente —el caso paradigmático es Spring Boot 2.7 → 3.0, con el salto de javax a jakarta— no es un cambio de número. Este es el procedimiento que funciona.

Paso 0: tener pruebas. Sin la suite del módulo 6, una actualización mayor es un salto al vacío. Si el proyecto no las tiene, escribirlas es el primer paso de la migración, no una tarea aparte.

Paso 1: leer la guía de migración entera, antes de tocar nada. Está en el wiki del repositorio de Spring Boot y enumera los cambios incompatibles uno a uno. Media hora de lectura ahorra días.

Paso 2: spring-boot-properties-migrator. Una dependencia temporal que, al arrancar, informa de las propiedades renombradas o retiradas y aplica temporalmente las equivalencias:

Arrancas, lees el informe del log, corriges el YAML y quitas la dependencia. Dejarla puesta es un error clásico: enmascara los problemas en lugar de resolverlos.

Paso 3: OpenRewrite para lo mecánico. Las migraciones repetitivas —javax.* a jakarta.*, anotaciones retiradas, APIs renombradas— las hace una receta automática:

Es un cambio masivo, así que va en un commit propio, sin mezclar nada, y se revisa leyendo la diferencia. OpenRewrite hace el 80 % del trabajo mecánico; el 20 % restante —lo que requiere criterio— sigue siendo tuyo.

Paso 4: subir de una versión menor cada vez. De 2.5 a 3.3 no se salta: se va 2.5 → 2.6 → 2.7 → 3.0 → …, con la suite en verde en cada escalón. Si algo se rompe, sabes exactamente qué escalón lo rompió.

Paso 5: revisar lo que el BOM no gestiona. Las dependencias con <version> propia —en CicloUrbana, JJWT, ShedLock, MapStruct, Resilience4j— no las sube Spring Boot. Son las que quedan atrás y las que dan sorpresas.

Paso 6: desplegar en pre y medir. Una actualización mayor puede cambiar el rendimiento en ambas direcciones. La línea base de k6 del módulo 9 existe exactamente para esto.

Spring Boot vive sobre Java, y desde hace unos años Java se mueve deprisa.

Versiones LTS y qué aportan. Las versiones con soporte extendido salen cada dos años, y son las que se usan en producción:

De todo lo anterior, lo que ya usa CicloUrbana a diario son los record de los DTOs, los bloques de texto de las consultas JPQL, el switch como expresión y los hilos virtuales.

Project Loom y los hilos virtuales. Es el cambio conceptual más importante de la última década en Java: un hilo que al bloquearse en entrada/salida libera el hilo del sistema operativo en lugar de ocuparlo. Para una aplicación bloqueante con mucha espera de base de datos —que es la inmensa mayoría de las aplicaciones de gestión— permite alta concurrencia sin pila reactiva.

Ese fragmento con hilos de plataforma agotaría la memoria mucho antes de llegar al millón. Merece la pena entenderlo a fondo, incluidas sus dos trampas: el pinning con synchronized y el hecho de que el límite real pasa a ser el pool de conexiones, como vimos en 09-01.

GraalVM e imágenes nativas. Compilar la aplicación a un ejecutable nativo reduce el arranque de segundos a milisegundos y la memoria a una fracción. A cambio, la compilación tarda minutos, la reflexión necesita RuntimeHints explícitos y el rendimiento sostenido puede ser algo menor que con la JVM. Su caso claro son las funciones sin servidor y los procesos de vida corta; para un servicio que arranca una vez al día, aporta poco.

Y una idea de fondo: Spring Boot es la parte más visible de tu trabajo, pero la que más se transfiere es Java. Un buen conocimiento del lenguaje, de la JVM y de la concurrencia sobrevive a cualquier framework.

Solo obras ampliamente reconocidas, con a quién le sirve cada una. Un libro se lee en semanas y se consulta durante años; es el formato con mejor retorno a largo plazo.

Si tuvieras que elegir tres para los próximos seis meses, partiendo de donde estás: Effective Java (te hace mejor programador Java, no mejor usuario de Spring), High-Performance Java Persistence (porque la base de datos es donde está el tiempo) y Designing Data-Intensive Applications (porque es el que amplía la visión más allá de una aplicación).

La certificación de referencia del ecosistema es la VMware Spring Professional, que cubre contenedor, AOP, datos, MVC, seguridad, Boot y pruebas: aproximadamente el temario de este curso.

Una valoración honesta:

Cuándo compensa, en concreto: si trabajas en una consultora donde influye en la asignación de proyectos o en la tarifa; si tu empresa la paga y te da tiempo; o si necesitas una estructura externa para estudiar de forma consistente. Cuándo no: si el objetivo es demostrar que sabes. Para eso, un proyecto público bien hecho —con pruebas, canalización y README decente— dice muchísimo más, y es lo que de verdad se mira en una entrevista técnica.

Existen además certificaciones adyacentes que en muchos contextos valen más que la de Spring: las de Kubernetes (CKA y CKAD) y las de los proveedores de nube, porque cubren un área donde la demanda supera con claridad a la oferta y donde el examen es práctico, con una terminal de verdad, en lugar de una batería de preguntas. Si el objetivo es la empleabilidad y ya sabes Spring Boot, esa dirección suele ser mejor inversión.

Y el consejo sobre preguntar, que sirve en cualquiera de estos sitios: una buena pregunta incluye la versión de Spring Boot, un ejemplo mínimo que reproduzca el problema, el mensaje de error completo y lo que ya has intentado. Preparar esa pregunta resuelve el problema por sí sola una de cada tres veces, y el fenómeno tiene nombre —rubber duck debugging—: la obligación de explicar el problema con precisión te hace ver el hueco de tu razonamiento.

Sobre el rastreador de incidencias, que merece un párrafo propio porque casi nadie lo usa: cuando Spring hace algo que no entiendes, hay una probabilidad alta de que alguien ya lo haya reportado, y de que un miembro del equipo haya explicado por qué funciona así. Esas respuestas son con frecuencia mejores que la documentación, porque responden a la pregunta exacta que tú tienes. Buscar el mensaje de error literal entre comillas es el primer movimiento, antes de escribir en ningún foro.

Leer sobre programación no enseña a programar, igual que leer sobre natación no enseña a nadar. Cuatro formas de practicar que sí funcionan:

Proyectos propios de dificultad creciente. El error habitual es empezar por «una red social»: demasiado grande, se abandona en la semana tres. Una progresión que funciona:

Las siete extensiones de 10-04 cubren exactamente esa progresión sobre un proyecto que ya conoces.

Contribuir a un proyecto libre. Empieza por documentación o por una incidencia etiquetada como buena para empezar. Lo que se aprende no es tanto el código como el proceso: revisiones exigentes, pruebas obligatorias, discusiones de diseño en abierto. Es la forma más barata de trabajar con gente mejor que tú.

Katas y ejercicios cortos. Repetir un problema pequeño concentrándote en una cosa cada vez —esta vez con TDD, esta vez sin if, esta vez con nombres perfectos— es lo más parecido a practicar escalas. Media hora a la semana.

Leer código ajeno. El hábito más infravalorado. Elige un proyecto Spring Boot bien valorado en GitHub y léelo como se lee un libro: la estructura de paquetes, un servicio, sus pruebas, su canalización. Vas a encontrar decisiones distintas a las de este curso, y entender por qué las tomaron es más formativo que estar de acuerdo.

Y una advertencia sobre las tres primeras: la práctica sin retroalimentación no es práctica deliberada, es repetición. Escribir código que nadie revisa consolida tanto los aciertos como los errores. Las tres fuentes de retroalimentación disponibles, de más a menos accesible, son: las pruebas, que te dicen si funciona; las herramientas de 10-03 —ArchUnit, SpotBugs, el análisis estático—, que te dicen si está bien construido; y una persona, que es la única que te dice si está bien pensado. Si trabajas solo, contribuir a un proyecto libre es la forma más barata de conseguir la tercera.

Todos estos parten de algo que ya sabes. La tercera columna es la que importa: dice qué lección te dejó preparado.

Cuál elegir primero. No el que más suene, sino el que resuelva un problema que tengas. Si tu aplicación pierde trabajo cuando se reinicia, mensajería. Si dos equipos se pisan en el mismo código, Spring Modulith. Si el dominio se te está diluyendo en los servicios, DDD táctico. Y si nada te duele todavía, el orden que mejor consolida lo aprendido es Spring Modulith → mensajería → DDD táctico.

Tres preguntas, en este orden, antes de invertir tiempo en un artículo, un vídeo o un curso:

1. ¿De cuándo es? Si no hay fecha visible, desconfía. Un artículo sin fecha sobre un framework que publica dos versiones al año no es un recurso, es un riesgo.

2. ¿Qué versión de Spring Boot usa? Es la pregunta decisiva, y casi siempre se responde mirando el código en diez segundos:

Por qué un tutorial de Spring Boot 2 confunde más de lo que ayuda. No es que esté «un poco anticuado»: es que el código no compila en un proyecto Boot 3 —cambian los paquetes de todas las anotaciones de persistencia, validación y servlet— y, peor, la explicación conceptual sigue siendo plausible. El lector novato no distingue entre «esto ya no existe» y «esto lo he escrito mal», y pierde horas. Con la tabla anterior, esos diez segundos de comprobación te ahorran la tarde.

3. ¿Quién lo firma y qué se juega? Un artículo del equipo de Spring, de un autor con trayectoria o de un proyecto con revisión entre pares tiene un incentivo para estar bien. Un contenido optimizado para posicionamiento, no.

Y un cuarto criterio que aplica sobre todo al contenido generado automáticamente, cada vez más abundante: si el código no se puede ejecutar tal cual, sospecha. Los ejemplos que mezclan versiones, inventan métodos que no existen o llaman a APIs de dos épocas distintas son la firma característica.

Una propuesta concreta y razonada para quien termina este curso y quiere consolidar en lugar de dispersarse. El principio que la ordena: cada mes tiene una entrega, y cada entrega se apoya en la anterior.

Por qué este orden y no otro. El mes 1 no aprende nada nuevo a propósito: lo recién visto se consolida usándolo, no añadiendo temas encima. El mes 2 es Java y no Spring porque es lo que más se transfiere y lo que menos caduca. El mes 3 ataca donde de verdad está el tiempo. El 4 y el 5 son los dos saltos conceptuales —comunicación asíncrona y diseño de dominio— y van después de tener la base sólida. Y el 6 cierra el ciclo, porque operar lo que uno construye es lo que convierte a un programador en un ingeniero.

Cómo hacerla realista. Cuatro o cinco horas a la semana, con una entrega visible cada mes. Un plan de veinte horas semanales no se cumple y produce culpa; uno de cinco horas mantenido seis meses produce un cambio real. Y si algún mes no sale, no se salta: se retrasa. La secuencia importa más que el calendario.

Y si tu situación es otra, adáptala con este criterio en lugar de copiarla. Si estás buscando trabajo, mueve el mes 6 al principio: un proyecto desplegado y observable es lo que se enseña en una entrevista. Si tu equipo va a partir el monolito el trimestre que viene, adelanta el mes 4 y añade Designing Data-Intensive Applications. Si acabas de entrar en un proyecto heredado, los meses 1 y 2 se sustituyen por escribir pruebas de caracterización y actualizar la versión, que es lo que desbloquea todo lo demás. La hoja de ruta correcta es la que ataca el problema que tienes hoy, no la que cubre más temas.

Coleccionar recursos en lugar de usarlos. Cincuenta pestañas abiertas y tres cursos empezados producen la sensación de estar aprendiendo y ningún aprendizaje. Un recurso a la vez, con un problema delante.

Seguir un tutorial sin comprobar la versión. Es la causa número uno de horas perdidas con Spring. Diez segundos mirando si dice javax o jakarta te los ahorran.

Aprender lo nuevo antes de dominar lo actual. WebFlux, GraalVM o Spring AI son interesantes; si aún no tienes claro cómo funciona el proxy de @Transactional, no son tu siguiente paso.

Copiar configuración sin entenderla. Un application.yml copiado de un blog trae propiedades que no necesitas, algunas peligrosas —ddl-auto: update, Actuator abierto, show-sql activo— y ninguna explicación.

Confundir «he leído sobre esto» con «sé hacer esto». La prueba es sencilla y es implacable: abrir el IDE y hacerlo sin mirar.

Aceptar sin verificar el código que sugiere un asistente. Los modelos de lenguaje se entrenan con todo lo que hay publicado, y lo que hay publicado sobre Spring Boot es mayoritariamente de la era 2.x: verás WebSecurityConfigurerAdapter, javax.persistence y @MockBean con una seguridad absoluta. Son herramientas excelentes para explorar y para escribir lo repetitivo, y aplican exactamente los mismos criterios del apartado 12: comprueba la versión, ejecútalo y no lo pegues si no lo entiendes.

Estudiar solo lo que ya te gusta. Es cómodo profundizar en lo que uno domina y evitar lo que le resulta ajeno —para muchos programadores, la operación y la base de datos—. Y es justo ahí donde suele estar la mayor diferencia entre lo que sabes y lo que el proyecto necesita.

Consejo: escribe lo que aprendes. Un artículo, una nota interna o un archivo docs/decisiones/ en tu proyecto. Explicar algo obliga a entenderlo de verdad, y descubre los huecos que la lectura pasiva esconde.

Consejo: mantén un proyecto vivo. Un repositorio propio al que vuelves cada pocas semanas vale más que diez cursos. Es donde probar cada cosa nueva y donde comprobar si funciona en tus manos y no solo en las del autor.

Consejo: aprende a leer código antes que a escribirlo. La mayor parte de tu carrera la pasarás leyendo: el código de tu equipo, el de un framework, el de alguien que se fue hace tres años. Es una habilidad que se entrena, y casi nadie la entrena a propósito.

Consejo: cuando algo te sorprenda, para y entra. Ese instante de «anda, no sabía que hacía eso» es la mejor señal de aprendizaje disponible, y se desperdicia casi siempre porque hay prisa. Diez minutos leyendo la clase que lo provoca valen más que dos horas de un curso sobre algo que no te ha sorprendido nunca.

Consejo: la mejor forma de estudiar un tema nuevo es escribir el ejemplo más pequeño posible. No un proyecto: un módulo Maven de tres clases que hace una cosa. Un consumidor de Kafka que imprime mensajes. Un @Observed que produce un span. Es rápido de escribir, rápido de tirar, y contesta preguntas que ningún artículo contesta.

Busca tres artículos o tutoriales sobre «Spring Boot JWT authentication» en cualquier buscador. Para cada uno, aplica los criterios del apartado 12 y redacta una ficha con: fecha, versión de Spring Boot deducida y con qué señal concreta la has deducido, si el código compilaría hoy, tres cosas que harías distinto según lo aprendido en el módulo 5, y tu veredicto final. Es muy probable que al menos uno esté desactualizado; el ejercicio consiste en detectarlo en menos de un minuto.

Descarga las fuentes con ./mvnw dependency:sources y abre DataSourceAutoConfiguration (o JacksonAutoConfiguration, si prefieres algo más corto). Responde: ¿qué condiciones deben cumplirse para que se active? ¿qué beans declara? ¿qué anotación hace que tu propio bean gane al suyo? ¿de qué clase *Properties lee la configuración y qué valores por defecto tiene? Y por último: ¿qué tendrías que hacer para sustituir por completo su DataSource por uno tuyo?

Adapta la hoja de ruta del apartado 13 a tu situación real. Parte de tres preguntas: ¿qué problema tienes hoy en tu trabajo o en tu proyecto que Spring Boot no te ha resuelto todavía?, ¿cuántas horas a la semana puedes sostener de verdad durante seis meses?, y ¿qué entrega visible marcaría cada mes? Escribe el resultado con una entrega por mes y un criterio objetivo para saber si la has cumplido.

Solución 1

Un ejemplo de ficha bien hecha, sobre un caso muy habitual:

Artículo A — Sin fecha visible (primera señal de alarma; en el pie del blog aparece 2021). Versión deducida: Spring Boot 2.5. Señales, por orden de contundencia: extiende WebSecurityConfigurerAdapter y sobrescribe configure(HttpSecurity), retirado en Spring Security 5.7; importa javax.servlet.FilterChain; usa antMatchers(...), sustituido por requestMatchers(...); y io.jsonwebtoken 0.9.1, cuya API Jwts.parser().setSigningKey(String) ya no existe en 0.12. ¿Compilaría hoy? No. Fallaría en los import de javax.* y en la clase base retirada, y ni siquiera llegaría a los errores de la API de JJWT. Tres cosas que haría distinto según el módulo 5: (1) SecurityFilterChain como bean en lugar del adaptador, con authorizeHttpRequests terminado en anyRequest().denyAll(); (2) el secreto por variable de entorno y de 256 bits, no una constante "secret" en el código; (3) token de acceso de quince minutos con refresco rotatorio, en lugar de las diez horas del artículo. Veredicto: descartar. No por antiguo, sino porque el error que enseña es de seguridad, que es la peor categoría para copiar sin entender.

Las tres señales que resuelven el 90 % de los casos en diez segundos: javax frente a jakarta, WebSecurityConfigurerAdapter, y spring-cloud-starter-sleuth. Si aparece cualquiera de las tres, el recurso es de la era Spring Boot 2.

Y el matiz que evita ser injusto: un recurso antiguo puede seguir siendo conceptualmente correcto. La explicación de qué es un JWT, por qué se firma y por qué su carga útil es legible no ha cambiado. Lo que no se puede copiar es el código.

Solución 2

Sobre DataSourceAutoConfiguration, las respuestas y —más importante— lo que enseña cada una:

¿Qué condiciones la activan? @ConditionalOnClass({DataSource.class, EmbeddedDatabaseType.class}), es decir, solo si esas clases están en el classpath. De ahí la regla que explica toda la autoconfiguración: añadir un starter de datos no «enciende» nada mágicamente; simplemente pone clases en el classpath y las condiciones se cumplen.

¿Qué beans declara? Un DataSource, resuelto en configuraciones anidadas: si detecta HikariCP lo usa (@ConditionalOnClass(HikariDataSource.class)), y si no prueba con Tomcat JDBC o DBCP2, en ese orden. También declara DataSourceInitializer y los beans de propiedades.

¿Qué hace que tu bean gane? @ConditionalOnMissingBean. Es la anotación clave de todo Spring Boot: la autoconfiguración solo actúa si tú no has decidido nada. Declarar tu propio @Bean DataSource la desactiva sin necesidad de excluir nada.

¿De dónde lee? De DataSourceProperties (prefijo spring.datasource), donde están url, username, password, driverClassName, generate-unique-name y el resto, con sus valores por defecto escritos en los campos —que es más rápido de consultar que la documentación—.

¿Cómo sustituirlo del todo? Tres formas, de mejor a peor: declarar tu propio @Bean DataSource, que gana por @ConditionalOnMissingBean; excluirla con @SpringBootApplication(exclude = DataSourceAutoConfiguration.class); o quitar la dependencia, con lo que la condición de clase deja de cumplirse.

Lo que el ejercicio enseña de verdad no es esta clase, sino el patrón: @ConditionalOnClass + @ConditionalOnMissingBean + una clase *Properties. Con eso entiendes las doscientas autoconfiguraciones restantes, incluida la del starter propio que escribimos en 02-06. Y confirma la afirmación del apartado 3: cuando lees el código, la magia desaparece.

Solución 3

No hay solución única, pero sí una forma reconocible de haber hecho bien el ejercicio. Un ejemplo:

Situación: trabajo en un equipo de cuatro personas con un monolito Spring Boot 2.7 que nadie se atreve a actualizar. Puedo sostener cuatro horas a la semana. El problema real no es técnico: es que no hay pruebas y por eso nadie toca nada.

Mes	Foco	Entrega	Criterio objetivo
1	Pruebas de caracterización de los tres flujos críticos	Suite que se ejecuta en CI	./mvnw verify en verde en la canalización, no en mi portátil
2	Actualización a Spring Boot 3, escalón a escalón	Rama con 2.7 → 3.0 → 3.3	La suite del mes 1 en verde en cada escalón
3	Effective Java + refactorización de un módulo	Módulo de facturación limpio	Diez elementos aplicados, documentados en docs/decisiones/
4	Rendimiento: k6, EXPLAIN ANALYZE, índices	Línea base y una mejora medida	p95 del endpoint peor por debajo de 300 ms
5	Observabilidad: métricas, logs y trazas	Cuadro de mando y dos alertas	Provocar un incidente y diagnosticarlo en menos de diez minutos
6	Spring Modulith	Fronteras entre facturación y pedidos	Reglas de ArchUnit que fallan si alguien las cruza

Lo que hace buena esta hoja de ruta: el mes 1 no es «aprender algo», es quitar el bloqueo real —sin pruebas no se puede hacer nada de lo demás—; cada mes tiene un criterio objetivo y verificable, no «entender X»; el orden respeta las dependencias entre temas; y las horas son las que la persona puede sostener de verdad, no las que le gustaría.

El error típico al hacer este ejercicio es escribir una lista de tecnologías que suenan bien —Kafka, Kubernetes, WebFlux, GraalVM— sin ningún problema detrás. Una hoja de ruta sin un problema que resolver se abandona en la semana cinco.

Y una comprobación final que conviene hacerse: si dentro de seis meses cumplieras el plan entero, ¿qué sabrías hacer que hoy no sabes? Si la respuesta se puede formular con verbos —«actualizar un proyecto heredado sin miedo», «diagnosticar un p99 alto en diez minutos»— el plan es bueno. Si solo se puede formular con sustantivos —«Kafka», «Kubernetes»—, todavía es una lista de temas y no una hoja de ruta.

Aquí termina el curso, y conviene mirar el camino completo antes de cerrarlo.

Empezamos en 01-03 con un @RestController de nueve líneas que devolvía cuatro estaciones escritas a mano y un curl que respondía en localhost:8080. Terminamos con CicloUrbana: una aplicación con un contrato REST versionado y documentado, con sus DTOs, su validación y sus errores en RFC 7807; con persistencia sobre PostgreSQL gobernada por nueve migraciones de Flyway y transacciones que garantizan que ninguna bicicleta de Ribalta quede bloqueada a medias; con autenticación JWT, jerarquía de roles y reglas de seguridad que dependen del dato y no solo de la ruta; con una suite de pruebas que va de la unidad de un milisegundo al flujo completo sobre un PostgreSQL real y efímero; con tareas programadas coordinadas entre réplicas y trabajo asíncrono que no bloquea al ciudadano; empaquetada en una imagen multietapa, desplegada en Kubernetes por una canalización que la construye, la escanea y la promociona sola; y observada de extremo a extremo, donde la métrica detecta, la traza localiza y el log explica, unidos por un mismo traceId. Y con el criterio, al final, para saber por qué está hecha así y dónde habría que romper cada regla.

Lo importante es que casi nada de eso es específico de Spring Boot. La inversión de control, la separación entre dominio y contrato, la atomicidad de un caso de uso, la denegación por defecto, la pirámide de pruebas, medir antes de optimizar, los percentiles en lugar de la media, las migraciones compatibles hacia atrás, un artefacto para todos los entornos, los secretos fuera del repositorio, los logs estructurados y correlacionados, la deuda técnica registrada con su coste: todo eso viaja contigo a cualquier framework, a cualquier lenguaje y a cualquier equipo. Spring Boot ha sido el vehículo; lo que has aprendido a conducir es más grande.

Quedan cosas por saber, y siempre quedarán. Es la parte incómoda y también la mejor de este oficio: nadie termina de aprenderlo, y la diferencia entre alguien con dos años de experiencia y alguien con quince no es el número de frameworks que conoce, sino la calidad de las preguntas que se hace antes de decidir. Este curso ha intentado, sobre todo, enseñarte esas preguntas: ¿qué problema resuelve esto?, ¿qué me cuesta?, ¿cómo sabré si funciona?, ¿qué pasa cuando falle?, ¿lo entenderá el próximo que lo lea?

Ahora te toca a ti. Coge CicloUrbana y llévala a algún sitio: añade las tarifas dinámicas, extrae la facturación, conéctala a un mapa. O empieza algo tuyo, más pequeño y más real, y hazlo bien de principio a fin. Lo que no funciona es esperar a saberlo todo antes de construir: se aprende construyendo, midiendo lo que se construye y arreglando lo que se rompe.

La red de Ribalta está en marcha. Gracias por llegar hasta aquí, y buen viaje.