El recorrido técnico del curso terminó en el módulo anterior: los veintitrés patrones del GoF construidos sobre PideYa y el catálogo moderno de arquitecturas, microservicios y concurrencia. Pero un curso, por completo que sea, es un mapa: el territorio se explora leyendo a los autores originales, contrastando opiniones y volviendo a las fuentes cuando un problema real te lo exija. En esta lección seleccionamos los libros que de verdad merecen tu tiempo, con un criterio claro para cada uno: por qué leerlo, cuándo hacerlo y qué módulo del curso amplía. No es una lista exhaustiva; es una biblioteca mínima y honesta.

1. Cómo leer esta lista (y cómo no leerla)
2. Los clásicos fundacionales: GoF y POSA
3. Los didácticos: Head First Design Patterns
4. Refactorización: Fowler y Kerievsky
5. La escuela "Clean": Clean Code y Clean Architecture, con mirada crítica
6. Java idiomático: Effective Java
7. Arquitectura empresarial y dominio: PoEAA, DDD y Vernon
8. Sistemas distribuidos y producción: Kleppmann y Nygard
9. Tabla resumen por nivel y objetivo
10. Rutas de lectura sugeridas según tu perfil

Antes de las recomendaciones, tres advertencias que valen más que cualquier título concreto:

• No los leas todos, y menos seguidos. Una biblioteca técnica se construye en años, al ritmo de los problemas que encuentras. Leer Designing Data-Intensive Applications sin haber tocado nunca un sistema distribuido es como estudiar el manual de vuelo sin avión.
• Distingue libros de lectura y libros de referencia. Algunos se leen de corrido (Head First, Clean Code); otros se consultan cuando duele algo (GoF, PoEAA, POSA). Confundir el tipo de libro es la primera causa de abandono en la página 80.
• Ningún libro es dogma. Todos los autores de esta lista se contradicen entre sí en algún punto. Eso no es un defecto de la lista: es la naturaleza del diseño de software.

Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson, Vlissides, 1994) es el libro que dio nombre a este curso. Pero conviene decirlo claro: hoy no se lee de corrido. Los ejemplos están en C++ y Smalltalk, el tono es académico y varios problemas que resolvía (como la ausencia de lambdas o de genéricos) ya no existen en el Java moderno. Se lee así:

• Primero la introducción y el capítulo del caso de estudio (Lexi): ahí está la filosofía — "programa contra interfaces", "prefiere composición sobre herencia" — que trabajamos en el módulo 1.
• Después, como referencia: cuando dudes sobre la intención exacta de un patrón, la sección Intent, Applicability y Consequences de su capítulo sigue siendo la fuente más precisa que existe. Nuestras lecciones de los módulos 2 a 4 son, en el fondo, una traducción de esas secciones al mundo de PideYa.

Pattern-Oriented Software Architecture (POSA), la serie iniciada por Buschmann y otros, es el siguiente escalón: patrones de arquitectura (Layers, Broker, Pipes and Filters) y de concurrencia. Es denso y muy de referencia; su volumen 1 amplía directamente lo que vimos en la lección de arquitecturas del módulo 6, y el volumen 2 lo que vimos en concurrencia.

Head First Design Patterns (Freeman y Robson) es probablemente el mejor primer libro de patrones jamás escrito: ejemplos en Java, humor, repetición deliberada y un enfoque en la intención antes que en el diagrama. Si este curso te ha costado en algún módulo, este libro es la segunda pasada ideal. Su límite: cubre unos 14 patrones, no los 23, y su estilo visual no es para todo el mundo. La segunda edición actualizó los ejemplos a Java 8+.

Esta pareja amplía directamente la lección de Refactorización Usando Patrones de Diseño:

• Refactoring (Martin Fowler): el catálogo de transformaciones pequeñas y seguras. La segunda edición usa JavaScript, pero las refactorizaciones son universales. Es el libro que convierte "este código huele mal" en un plan de acción con nombre y pasos.
• Refactoring to Patterns (Joshua Kerievsky): el puente entre ambos mundos. Su tesis — se refactoriza hacia un patrón cuando el código lo pide, no se diseña con el patrón desde el día uno — es exactamente la disciplina que aplicamos cuando convertimos los condicionales de envío de PideYa en un Strategy.

Clean Code y Clean Architecture (Robert C. Martin) son enormemente influyentes y conviene leerlos, pero con criterio propio:

• Lo valioso: la insistencia en nombres significativos, funciones pequeñas, la regla de dependencia (las dependencias apuntan hacia el dominio) y la formulación de SOLID que estudiamos en el módulo 1. Clean Architecture conecta muy bien con nuestra lección de arquitectura hexagonal.
• Lo discutible: algunas reglas de Clean Code (funciones de 2-4 líneas, evitar casi todo comentario) llevadas al extremo producen código fragmentado y difícil de seguir; la comunidad lleva años debatiéndolo. Léelo como una colección de heurísticas de un practicante con opiniones fuertes, no como un reglamento.

Effective Java (Joshua Bloch, 3.ª edición) no es un libro "de patrones" y sin embargo es el que más patrones reales por página contiene: Builder (ítem 2, la base de nuestro Pedido.Builder), factorías estáticas, Singleton con enum, inmutabilidad (clave en el módulo de concurrencia), composición sobre herencia (ítem 18)… Si programas en Java a diario, es posiblemente el libro más rentable de toda esta lista. Se lee bien por ítems sueltos, en cualquier orden.

• Patterns of Enterprise Application Architecture (PoEAA) (Fowler): el catálogo del que salen Repository, Unit of Work, Data Mapper o Lazy Load — los patrones que reconociste dentro de Spring e Hibernate en el módulo 5. Muy de referencia: se consulta el patrón que necesitas.
• Domain-Driven Design (Eric Evans): el "libro azul". Lenguaje ubicuo, agregados, bounded contexts — el vocabulario con el que en el módulo 6 decidimos dónde cortar PideYa en microservicios. Denso; su primera mitad (el lenguaje y el modelo) es la más importante.
• Implementing Domain-Driven Design (Vaughn Vernon): el "libro rojo", la versión práctica del anterior, con código y decisiones concretas. Muchos lectores lo aprovechan mejor leyéndolo antes o en paralelo al de Evans.

• Designing Data-Intensive Applications (Martin Kleppmann): el libro que amplía casi todo el módulo 6 — replicación, particionado, transacciones distribuidas, CAP explicado sin mitos, event sourcing y logs. Riguroso y a la vez legible; el consenso de la industria lo considera lectura obligada para trabajar en sistemas distribuidos.
• Release It! (Michael Nygard, 2.ª edición): el origen del patrón Circuit Breaker que aplicamos entre los servicios de PideYa, junto a Bulkhead, timeouts y las historias de guerra de sistemas cayendo en producción. Es el libro que convierte "funciona en mi máquina" en "sobrevive un viernes por la noche con la app llena de pedidos".

Ningún perfil necesita las doce obras. Tres rutas orientativas:

La regla común a las tres rutas: un libro de lectura a la vez, los de referencia siempre a mano, y cada capítulo contrastado contra código real — el tuyo del trabajo o tu propia implementación de PideYa.

• Error: empezar por el GoF de corrido. Es el error clásico del recién convencido. El GoF es una referencia magnífica y una lectura lineal frustrante. Empieza por Head First y vuelve al GoF por capítulos sueltos.
• Error: coleccionar libros en lugar de leerlos. Comprar doce libros produce una estantería, no un criterio. Compra el siguiente cuando termines (o abandones conscientemente) el actual.
• Error: leer sin código delante. Un capítulo de Refactoring sin aplicarlo a código real se olvida en una semana. Ten siempre un proyecto (PideYa sirve) donde ensayar lo que lees.
• Error: tomar cualquier autor como dogma. Fowler y Martin discrepan; Evans y los críticos de DDD discrepan. Cuando dos autores solventes se contradicen, ahí es exactamente donde está tu oportunidad de formar criterio propio.
• Consejo: lleva un cuaderno (o un fichero de notas) de lecturas: por cada capítulo, una idea aplicable y dónde la aplicarías en tu código actual. Convierte lectura pasiva en diseño activo.

De la tabla por perfiles, elige la ruta que mejor te describa (o mezcla dos). Escribe tu plan: los 3 primeros libros, en orden, con una fecha objetivo realista para cada uno y una frase que justifique por qué ese libro en ese momento de tu carrera.

Elige el patrón del curso que peor recuerdes (sé honesto). Busca su capítulo en el GoF (o su ficha en una referencia fiel al GoF) y lee solo las secciones Intent, Applicability y Consequences. Anota: ¿qué matiz de la intención original no habías captado en el curso?

Toma una regla concreta de Clean Code (por ejemplo, "las funciones deben ser muy cortas") y escribe dos párrafos: uno defendiéndola con un ejemplo de PideYa donde ayudaría, y otro mostrando un caso donde aplicarla a rajatabla empeoraría el código.

Ejercicio 1 (orientativa): un plan válido para un perfil júnior podría ser: Head First (3 meses, "necesito consolidar los patrones GoF con otra voz"), Effective Java por ítems (6 meses en paralelo con el trabajo, "programo Java a diario"), Refactoring (3 meses, "ya tengo código legado que me duele"). Lo importante es que cada elección responda a un problema tuyo actual, no a prestigio del título.

Ejercicio 2 (orientativa): es habitual descubrir matices como que Bridge se plantea desde el diseño inicial mientras Adapter aparece a posteriori, o que el GoF ya advertía de los costes de Visitor cuando la jerarquía de elementos cambia a menudo. Si encontraste un matiz así, el ejercicio cumplió su función: el GoF como referencia siempre da una capa más de precisión.

Ejercicio 3 (orientativa): a favor: trocear la FachadaCheckout en pasos pequeños con nombre (validar, cobrar, notificar) la hizo legible en el módulo 3. En contra: partir un algoritmo cohesionado de 15 líneas en seis funciones de 2 líneas obliga al lector a saltar entre ellas para reconstruir el flujo — la fragmentación también tiene coste. La conclusión razonable: la regla útil es "un nivel de abstracción por función", no un número de líneas.

Ya tienes la biblioteca mínima: los didácticos para consolidar, los clásicos como referencia, Fowler y Kerievsky para el día a día con código real, y Kleppmann, Nygard, Evans y Vernon para cuando PideYa — o tu sistema real — crezca hacia lo distribuido. La clave no es la lista sino el método: un libro a la vez, siempre con código delante y siempre con espíritu crítico. Los libros marcan el fondo; para el ritmo del día a día — referencias interactivas, charlas, katas — existe otro ecosistema de recursos en línea, y a él dedicamos la siguiente lección: Cursos y Tutoriales en Línea.