Los libros de la lección anterior marcan el fondo; el ecosistema en línea marca el ritmo. En internet hay material excelente sobre patrones de diseño — referencias interactivas, blogs de los propios autores, charlas de conferencia, katas de refactorización — y también toneladas de contenido superficial, copiado o desactualizado. Esta lección no te da una lista de enlaces para acumular en marcadores: te da una taxonomía de tipos de recurso, criterios para evaluar cada uno y, sobre todo, un plan de práctica deliberada con PideYa como proyecto personal, porque los patrones no se aprenden viendo vídeos sino escribiendo código.

1. Los tipos de recurso en línea (y para qué sirve cada uno)
2. Referencias interactivas: refactoring.guru y sourcemaking
3. Blogs de autores: martinfowler.com y compañía
4. La documentación oficial como fuente de patrones reales
5. Plataformas de cursos: cómo evaluar sin lista de la compra
6. Charlas y canales: GOTO, Devoxx y las conferencias en YouTube
7. Katas y práctica deliberada
8. PideYa como proyecto personal: el ejercicio integrador
9. Contenido desactualizado: cómo detectarlo

Cada tipo de recurso sirve para una fase distinta del aprendizaje. Usar el tipo equivocado para la fase equivocada es la principal fuente de frustración:

refactoring.guru es hoy la referencia visual más popular de los patrones GoF: cada patrón con su problema, solución, diagramas, pseudocódigo y ejemplos en varios lenguajes (Java incluido), más un catálogo de refactorizaciones y code smells alineado con Fowler. Es ideal como segunda opinión tras este curso: cuando dudes de un patrón, contrasta su ficha con lo que construimos en PideYa.

sourcemaking.com es su predecesor espiritual: mismo territorio (patrones, antipatrones, refactoring), estilo más antiguo. Útil sobre todo por su catálogo de antipatrones, que amplía nuestra lección del módulo 5.

Advertencia común a ambos: sus ejemplos son deliberadamente pequeños y didácticos. El riesgo es memorizar la miniatura y no reconocer el patrón a tamaño real — por eso este curso insistió en un dominio continuo como PideYa.

martinfowler.com es probablemente el sitio individual más valioso de esta lección: el catálogo de PoEAA en línea, el bliki con definiciones canónicas (de "Microservices" a "StranglerFigApplication", el origen del patrón que usamos en el módulo 6), y artículos largos sobre refactorización, CI/CD y arquitectura evolutiva. Léelo cuando un término del curso te pida profundidad: casi siempre hay una entrada suya que lo fijó.

El blog de Robert C. Martin (Uncle Bob) complementa con opiniones fuertes sobre principios SOLID, arquitectura limpia y profesionalismo. Igual que con sus libros: material valioso, tono vehemente — léelo con el criterio propio que ya has entrenado.

Un hábito que distingue a quien de verdad domina patrones: leer la documentación oficial buscando el patrón. Lo practicamos en el módulo 5 y conviene mantenerlo:

• Javadoc del JDK: Iterator, los factory methods de List.of/Collectors, el Builder de StringBuilder y HttpRequest, Observer en java.util.concurrent.Flow, Decorator en java.io.
• Documentación de Spring: Template Method en JdbcTemplate, Proxy en AOP y @Transactional, Singleton como scope por defecto, Strategy en toda la configuración enchufable.

La documentación oficial nunca está desactualizada respecto a su versión y muestra decisiones de diseño tomadas por equipos expertos con restricciones reales: es un curso de patrones gratuito escondido a plena vista.

En Coursera, Udemy o Pluralsight hay cursos de patrones buenos y malos, y los catálogos cambian constantemente, así que más útil que recomendar un título es darte la checklist de evaluación:

• ¿Lenguaje y versión? Un curso de patrones "en Java" grabado sobre Java 6 ignorará lambdas, records y Optional, y te enseñará soluciones hoy innecesariamente verbosas.
• ¿Ejemplos con dominio o miniaturas? Desconfía de cursos donde cada patrón vive en su ejemplo aislado de juguete (figuras geométricas, animales). Ya sabes por experiencia que el valor está en un dominio continuo.
• ¿Habla de cuándo NO usar el patrón? Un curso que solo vende ventajas no ha entendido el módulo 5 de este. Los trade-offs son la mitad del contenido.
• ¿Fecha de actualización y reseñas recientes? Reseñas de hace cinco años describen otro curso.
• ¿Hay ejercicios con código, no solo vídeo? Ver programar no es programar.

Si un curso pasa esta checklist, probablemente merece la pena, sea cual sea la plataforma.

Los canales de YouTube de conferencias como GOTO y Devoxx publican gratis miles de charlas de calidad: es donde la industria discute microservicios, DDD, arquitectura evolutiva o los límites de los patrones, a menudo por los mismos autores de los libros de la lección anterior. Cómo aprovecharlas:

• Úsalas para perspectiva, no para fundamentos: una charla de 45 minutos inspira y orienta, pero no sustituye la práctica.
• Busca por concepto del curso ("circuit breaker", "event sourcing", "hexagonal architecture") y filtra por los últimos 2-3 años para las tendencias, sin miedo a las charlas clásicas para los fundamentos.
• Regla práctica: por cada charla vista, una nota de una línea con la idea aplicable. Sin nota, la charla fue entretenimiento.

La práctica deliberada — ejercicios cortos, repetibles, con foco en una habilidad concreta — es al diseño lo que las escalas al piano:

• exercism: ejercicios por lenguaje con mentoría de la comunidad; su pista de Java es un buen gimnasio de idiomática.
• codewars: katas cortas por dificultad; útiles para soltura, menos para diseño (los problemas son pequeños).
• Katas de refactorización: las más valiosas para este curso. La Gilded Rose — que ya te propusimos en la lección de refactorización del módulo 5 — es la reina: código legado horrible con tests, perfecto para practicar el ciclo "test → refactorizar → patrón emerge". Otras conocidas: Tennis Refactoring Kata y Trip Service Kata (del ecosistema de Emily Bache y Sandro Mancuso, cuyos repositorios son fáciles de encontrar).

La clave de una kata no es terminarla sino repetirla: la segunda vez con otro patrón, la tercera con TDD estricto. La repetición con variación es lo que fija el criterio.

El mejor "curso online" que puedes hacer ahora no está en ninguna plataforma: es implementar PideYa de verdad. Durante el curso viste fragmentos; construirla completa te obligará a tomar todas las decisiones que un curso toma por ti. Plan sugerido por etapas:

Reglas del juego: tests desde el principio (módulo 6, TDD), cada patrón introducido cuando el código lo pida (Kerievsky, módulo 5) y un pequeño ADR por decisión de diseño. Un repositorio así, además, es el mejor portfolio de diseño que puedes enseñar en una entrevista.

El contenido en línea envejece sin avisar. Señales de alarma al evaluar un tutorial o curso:

• Singleton con doble comprobación como "la" solución, sin mencionar enum ni contenedores DI: material anterior a la conversación moderna (nuestra crítica del módulo 2).
• Java sin lambdas donde una lambda resolvería (Strategy u Observer con clases anónimas de diez líneas): anterior a Java 8, es decir, más de una década.
• "Los microservicios son siempre mejores" (o cualquier "siempre"): el péndulo de la industria ya volvió; el material serio habla de trade-offs, como hicimos en el módulo 6.
• Frameworks o versiones que ya no reconoces en los ejemplos, o capturas de herramientas con interfaces de hace muchos años.
• Ausencia total de tests en un tutorial de refactorización: contradice la definición misma de refactorizar.

Detectar material desactualizado no siempre significa descartarlo — los fundamentos envejecen bien — pero sí leerlo sabiendo qué parte ha caducado.

• Error: el coleccionismo de tutoriales. Cincuenta pestañas guardadas y ningún proyecto terminado. Regla inversa: máximo un recurso activo por tipo, y no se añade otro hasta cerrar el actual.
• Error: el "tutorial hell". Encadenar cursos en vídeo produce sensación de progreso sin progreso real. La proporción sana es aproximadamente 1 hora de consumo por 2-3 de práctica.
• Error: aprender patrones solo con miniaturas. Si todos tus ejemplos caben en una pantalla, no reconocerás el patrón en un sistema real. De ahí el proyecto PideYa.
• Error: ignorar la fecha del contenido. Un tutorial sin fecha visible ya es una señal; aplica la checklist de desactualización antes de invertir horas.
• Consejo: convierte lo que consumes en algo que produces — una nota, un commit en tu PideYa, un test nuevo. El aprendizaje sin artefacto se evapora.

Elige un tutorial o curso de patrones que tengas guardado (o busca uno cualquiera sobre Singleton en Java). Pásale la checklist de evaluación y la lista de señales de desactualización. Escribe un veredicto de tres líneas: ¿lo usarías?, ¿con qué precauciones?

Diseña un plan semanal realista (indica horas/semana) combinando al menos tres tipos de recurso de la tabla inicial y la etapa 1 del proyecto PideYa. Formato sugerido: semana → objetivo → recurso → artefacto producido.

Haz (o rehaz) la Gilded Rose. Primera pasada: solo refactorizaciones pequeñas apoyadas en los tests. Segunda pasada, otro día: introduce explícitamente un patrón del módulo 4 donde el código lo pida. Anota qué pasada te resultó más natural y por qué.

Ejercicio 1 (orientativa): un veredicto típico sobre un tutorial antiguo de Singleton: "Explica bien la intención, pero usa doble comprobación sin volatile (incorrecta) y no menciona enum ni DI; lo usaría solo para la motivación del patrón, nunca para la implementación". Fíjate en que el veredicto separa qué parte del recurso sigue siendo válida.

Ejercicio 2 (orientativa): ejemplo con 5 h/semana: S1 — dominio de PideYa (Composite de la carta) + ficha de Composite en refactoring.guru como contraste; S2 — extras con Decorator + una charla de GOTO sobre diseño OO con nota de una línea; S3 — Gilded Rose primera pasada; S4 — Builder del pedido + revisión: ¿qué patrón surgió sin planearlo? El criterio de calidad del plan: cada semana termina con código, no solo con contenido visto.

Ejercicio 3 (orientativa): la mayoría encuentra la primera pasada más segura (los tests mandan, pasos pequeños) y la segunda más tentadora de sobre-diseñar. Si en la segunda te sorprendiste metiendo un patrón "porque tocaba" y no porque el código lo pidiera, acabas de vivir en pequeño la lección de antipatrones del módulo 5 — ese autoconocimiento es exactamente el objetivo de la kata.

Ya sabes navegar el ecosistema: referencias interactivas para consultar, blogs de autores para el criterio, documentación oficial para ver patrones de verdad, charlas para la perspectiva, katas para el músculo y PideYa como proyecto integrador donde todo se junta. El hilo común es siempre el mismo: consumir menos, producir más, y desconfiar del material que no muestra sus fechas ni sus trade-offs. Pero aprender en solitario tiene un techo: el criterio de diseño se afila discutiendo con otros — preguntando bien, leyendo código ajeno, recibiendo revisiones. De eso trata la siguiente lección: Comunidades y Foros.