Has llegado al final. Empezaste este curso con una pregunta aparentemente simple — ¿qué es un patrón de diseño? — y lo terminas habiendo construido, pieza a pieza, una plataforma completa de pedidos a domicilio: PideYa. Lo que comenzó como una configuración global y un notificador de correos es hoy, en tu cabeza, un sistema con carta componible, checkout orquestado, pedidos con ciclo de vida, reparto coordinado y hasta una versión distribuida con sus sagas y sus circuit breakers. Esta última lección no introduce nada nuevo: mira atrás para fijar lo esencial, te da una vara de medir para autoevaluarte, y te propone los primeros 90 días del camino que sigue.

1. El viaje completo: PideYa como espejo
2. Las 7 ideas-fuerza del curso
3. Autoevaluación final: sabes X si puedes Y
4. Próximos pasos: una ruta de 90 días
5. Despedida

Cada módulo del curso dejó su capa en PideYa. Recorrerlas en orden es recorrer la madurez de cualquier diseñador de software:

Léelo de arriba abajo y verás la narrativa completa: de la definición de patrón al monolito bien diseñado, y del monolito bien diseñado a la plataforma distribuida. Ese orden no fue casual: nadie diseña bien un sistema distribuido sin haber diseñado bien antes un objeto.

Si dentro de cinco años solo recuerdas siete frases de este curso, que sean estas:

1. Los patrones son intenciones, no plantillas. Copiar el diagrama UML de Strategy no es aplicar Strategy; aplicarlo es reconocer "aquí hay una familia de algoritmos intercambiables". Por eso el mismo patrón cabe en tres líneas con lambdas o en cinco clases.
2. Composición sobre herencia. La lección silenciosa detrás de Decorator, Strategy, Bridge y media docena más: envolver y delegar da flexibilidad en tiempo de ejecución; heredar fija decisiones en tiempo de compilación. Los extras de un plato de PideYa lo demostraron mejor que cualquier teoría.
3. Espera hasta que duela. El patrón se introduce cuando el código lo pide — el tercer if sobre el tipo de envío, el segundo canal de notificación — no el primer día "por si acaso". La sobreingeniería es el lado oscuro de este catálogo, y la refactorización hacia patrones, su antídoto.
4. El nombre importa. Decir "esto es un Adapter" en una code review transmite en dos palabras un problema, una solución y sus consecuencias. El vocabulario común es, en el día a día, el beneficio más rentable de todo lo que has estudiado.
5. Programa contra interfaces, no contra implementaciones. El principio de 1994 que sostiene desde el Factory Method hasta la inyección de dependencias de Spring y los puertos de la arquitectura hexagonal. Una sola idea, treinta años de vigencia.
6. Todo diseño es un trade-off. Cada patrón compra flexibilidad pagando indirección; cada microservicio compra autonomía pagando complejidad distribuida. No existe la solución buena en abstracto: existe la adecuada a un contexto, y el contexto cambia.
7. Los catálogos crecen, pero las intenciones permanecen. Circuit Breaker es un Proxy que protege; API Gateway, una Facade en red; el Outbox, un problema de consistencia con ropa nueva. Quien domina las intenciones aprende cada patrón nuevo en minutos — y por eso este curso te sirve también para los patrones que aún no se han inventado.

El conocimiento de diseño no se mide recitando definiciones sino haciendo. Repasa esta lista con honestidad; cada "no" es simplemente tu siguiente objetivo de práctica:

Si has marcado la mayoría, no "te sabes los patrones": piensas en patrones, que era el objetivo real desde la primera lección.

El mayor riesgo al acabar un curso es el vacío del día siguiente. Propuesta concreta, ajustable a tu ritmo (asume 4-6 horas semanales):

Tres reglas para que el plan sobreviva al contacto con la realidad: cada semana termina con un artefacto (commit, nota, ADR — no solo lectura); si una semana se cae, se retoma sin culpa y sin "empezar de cero"; y al día 90, decide el siguiente ciclo tú mismo — ya tienes el criterio y el mapa de recursos para hacerlo.

• Error: cerrar el curso y no escribir código en un mes. Lo aprendido sin práctica inmediata se degrada rápido. El plan de 90 días existe exactamente para eso: empieza esta semana, aunque sea con una hora.
• Error: convertirse en el "evangelista de patrones" del equipo. Recién aprendido el martillo, todo parece clavo. Recuerda el módulo 5: el mejor diseñador es el que sabe cuándo no aplicar el patrón, y el vocabulario sirve para conversar, no para sentenciar.
• Error: medir el progreso por contenido consumido. Libros leídos y vídeos vistos no son la métrica; la métrica es la tabla de autoevaluación: qué puedes hacer hoy que no podías hace tres meses.
• Consejo: vuelve a este curso como referencia. Las comparativas de los módulos 2, 3 y 4 y el método de selección del módulo 5 están pensados para releerse con un problema real entre manos — así es como se usa un catálogo.
• Consejo: enseña lo que has aprendido. Una charla corta en tu equipo sobre tres patrones que encontraste en vuestro código vale más que releer tres capítulos: explicar es la prueba final de haber comprendido.

Recorre la tabla "sabes X si puedes Y" y, para cada fila, escribe una evidencia real ("lo demostré cuando...") o un "todavía no". Con los "todavía no", ordena tus tres prioridades y asigna cada una a un tramo de tu plan de 90 días.

Escribe media página dirigida a la persona que eras antes de la lección 01-01: qué tres cosas le dirías sobre los patrones de diseño para ahorrarle los malentendidos más caros. No repitas las ideas-fuerza literalmente; formúlalas con tus palabras y tus ejemplos.

Adapta la ruta de 90 días a tu realidad: tus horas disponibles, tu nivel según el ejercicio 1 y tus objetivos profesionales. Escríbela con fechas concretas en tu calendario y decide ahora la respuesta a la pregunta incómoda: ¿qué harás la semana que no cumplas?

Ejercicio 1 (orientativa): una evidencia válida es concreta y verificable: "Distingo Adapter de Decorator: lo demostré en la comparativa del módulo 3 y ayer identifiqué un Decorator en BufferedReader". Un "todavía no" típico es el ADR — pocos lo han escrito alguna vez — y por eso la ruta lo coloca en los días 61-90, cuando ya hay decisiones propias de PideYa que documentar.

Ejercicio 2 (orientativa): las cartas más lúcidas suelen girar sobre tres avisos: "los patrones no son recetas que aplicar sino problemas que reconocer", "no metas el patrón el primer día: espera al segundo o tercer caso real" y "aprende los nombres aunque te parezcan pedantería — el día que digas 'esto pide una Facade' en una reunión y todos asientan, entenderás para qué era todo esto". Si tu carta contiene avisos así con ejemplos propios, has interiorizado el curso.

Ejercicio 3 (orientativa): un buen plan personal es más pequeño que el propuesto, no más grande: si solo tienes 3 horas semanales, quizá PideYa llegue a la etapa 3 y no a la 4, y la contribución open source pase al siguiente ciclo. La respuesta madura a la pregunta incómoda no es "no fallaré" sino algo como: "retomo el lunes siguiente donde lo dejé, y si fallo tres semanas seguidas, reduzco el plan a la mitad en lugar de abandonarlo".

Hasta aquí el curso de Patrones de Diseño de Software. Empezó con una definición — una solución nombrada a un problema recurrente en un contexto — y esa definición fue creciendo hasta abarcar la carta de un restaurante, el undo de un panel de administración, el ciclo de vida de un pedido, una arquitectura hexagonal y una saga distribuida. PideYa fue el espejo: cada patrón dejó de ser un diagrama en cuanto tuvo un pedido, un repartidor o un pago detrás.

Te llevas tres cosas. Un catálogo: los veintitrés del GoF y sus herederos modernos, con sus intenciones y sus costes. Un criterio: elegir por el problema, esperar hasta que duela, medir siempre el trade-off. Y un vocabulario: la capacidad de decir "Adapter", "Strategy" o "Circuit Breaker" y ser entendido por cualquier equipo del mundo. El catálogo se consulta, el criterio se entrena y el vocabulario se conversa — por eso los tres mejoran con los años en lugar de caducar.

El resto es práctica: tu PideYa real esperando el primer commit, tu primer libro de la ruta, tu comunidad local, tus 90 días. Los patrones que aún no existen los aprenderás en minutos, porque las intenciones ya las conoces.

Gracias por llegar hasta el final. Ha sido un placer diseñar contigo. Ahora, a escribir código que valga la pena leer.