M14 — Patrones de software

Por qué existe

Los patrones son vocabulario compartido entre ingenieros: aceleran revisiones y ADRs. Mal usados se convierten en cargo cult (clases llamadas Factory que solo hacen new). En esta materia aplicas patrones en el código del piloto Agenda Ops (o en un módulo de práctica que luego integrarás en M17), siempre con justificación escrita en projects/m14-patrones/.

En resumen: aplicas pocos patrones con justificación (no nombres de adorno) en el dominio de citas, precios o notificaciones.

Objetivos de aprendizaje

Al terminar debes poder:

Reconocer cuándo un patrón GoF (Gang of Four (patrones de diseño)) aporta flexibilidad real vs complejidad innecesaria.
Implementar Strategy, Observer y Factory con tests unitarios mínimos.
Estructurar backend con Repository + Service acorde a M13.
Refactorizar un módulo “legacy” propio (código previo del plan o spike) sin cambiar comportamiento observable.
Documentar ≥5 patrones aplicados con ADR (registro de decisión de arquitectura) o ficha en projects/m14-patrones/.
Articular cuándo no usar Singleton u otros patrones sobrevalorados.

Cómo estudiar esta materia (lecciones)

M14 aplica patrones con justificación en el dominio Agenda Ops: L01–L16 en orden.

Un patrón por lección: leer → implementar en TypeScript → test → ADR o nota.
Marca la lección solo si cumples “Hecho cuando”.
Evidencia en projects/m14-patrones/ (o repo producto enlazado en README).
Cada patrón sin justificación escrita no cuenta para el proyecto.
Cómo estudiar.

Semana tipo (20 h)

Bloque	Horas	Qué haces
Lectura patrones	6–8	Lecciones de la semana (4× ~5 h)
Implementar + tests	6–8	Código en `src/`
ADR / fichas	4–6	Por qué cada patrón
Retro	1	Anti-patrón que evitaste

Si un día solo tienes 2 h: una lección práctica (pasos + evidencia). No saltes la lectura de esa lección.

Lecciones

Semana 1 — Patrones creacionales y Strategy (~20 h)

ID	Lección	~h
L01	Entorno M14 y Strategy de precios	5
L02	Factory Method para notificadores de canal	5
L03	Singleton: cuándo NO usarlo	5
L04	Cierre semana 1 — creacionales y bitácora	5

Semana 2 — Patrones estructurales y regresión (~20 h)

ID	Lección	~h
L05	Adapter para API de calendario externo	5
L06	Decorator para logging de operaciones de cita	5
L07	Facade para el flujo agendar cita	5
L08	Tests de regresión en API pública del módulo	5

Semana 3 — Patrones de comportamiento y P1 (~20 h)

ID	Lección	~h
L09	Observer para eventos de dominio	5
L10	Command para acciones admin reversibles	5
L11	Cierre P1 — Strategy, Observer y Factory	5
L12	Repaso comportamiento y anti-patrón propio	5

Semana 4 — Repository, Service y proyecto (~20 h)

ID	Lección	~h
L13	Repository — interfaz Cita sin SQL	5
L14	Service — capa aplicación de citas	5
L15	Refactor P3 — módulo legacy antes y después	5
L16	Cierre M14 — cinco patrones e integración M17	5

Empieza por L01 hoy.

Lecturas (mapa rápido)

Canon: Patrones de diseño — GoF (ed. ES si hay). Alternativa: Refactoring.Guru ES. Ver bibliografía.

Semana	Lecciones	Patrones / capítulos	Alternativa
1	L01–L04	Creacionales + Strategy precios	Refactoring.Guru Factory / Singleton (cuándo NO)
2	L05–L08	Estructurales: Adapter, Decorator, Facade	Tests de regresión en API (interfaz de programación de aplicaciones) pública
3	L09–L12	Comportamiento: Observer, Command; cierre P1	Strategy + Observer + Factory documentados
4	L13–L16	Repository / Service + refactor P3 + ≥5 patrones	`projects/m14-patrones/README.md`

Regla: patrón sin justificación escrita = no cuenta.

Ejemplo — Strategy (TypeScript)

export type CalculoPrecio = { calcular(base: number): number };

export const tarifaBase: CalculoPrecio = {
  calcular: (base) => base,
};

export const tarifaPromoDiez: CalculoPrecio = {
  calcular: (base) => Math.round(base * 0.9 * 100) / 100,
};

export function totalServicio(base: number, estrategia: CalculoPrecio): number {
  return estrategia.calcular(base);
}

Ejemplo — Repository (interfaz)

export interface CitaRepository {
  findById(id: string, negocioId: string): Promise<Cita | null>;
  save(cita: Cita): Promise<void>;
}
// La implementación Postgres vive en infrastructure; el dominio no importa SQL.

Temario semanal

Semana 1 — Patrones creacionales (~20 h)

Factory Method / Abstract Factory (solo si hay varias familias de objetos).
Singleton: cuándo evitarlo (estado global, tests difíciles).
Implementación práctica: Factory para crear notificadores o parsers de canal (email vs WhatsApp link).
Ficha ADR por patrón creacional usado.

Semana 2 — Patrones estructurales (~20 h)

Adapter para integrar librería de terceros con tu interfaz de dominio.
Decorator para añadir logging o métricas sin ensuciar el core.
Facade para simplificar un subsistema (p. ej. “agendar cita” que coordina validación + persistencia).
Tests de regresión en comportamiento público.

Semana 3 — Patrones de comportamiento (~20 h)

Strategy (precios, políticas de no-show).
Observer (eventos de dominio: cita creada → auditoría o recordatorio futuro).
Command (opcional: cola de acciones admin reversibles).
Cierre P1: Strategy + Observer + Factory documentados con tests.

Semana 4 — Capas Repository/Service + proyecto (~20 h)

Repository + Service en backend alineado a M13.
Refactor P3: módulo legacy propio (antes/después + diff en notas).
ADR resumen: ≥5 patrones con contexto Agenda Ops.
Plan de integración en repo M17 si el código vive en projects/m14-patrones/.

Prácticas

P1 — 3 patrones: Strategy, Observer y Factory con tests en projects/m14-patrones/src/ (o repo producto con ruta documentada).
P2 — Repo/Service: Capa backend (aunque sea spike) con interfaces de dominio separadas de Postgres.
P3 — Refactor: projects/m14-patrones/refactor-notas.md con módulo antes/después y commits o diff.

Proyecto útil

≥5 patrones justificados en Agenda Ops: entrega en projects/m14-patrones/:

Índice README.md listando patrón → archivo → ADR.
Código ejecutable y tests verdes.
ADRs cortos (uno por patrón o uno consolidado con 5 subsecciones).

Errores comunes

Nombrar clases XFactory sin encapsular creación variable.
Singleton para “conexión DB” sin entender inyección de dependencias.
Over-engineering: 12 patrones en un CRUD (crear, leer, actualizar y borrar) de 200 líneas.
Copiar ejemplos de Java sin adaptar al estilo TypeScript del plan.
Patrones en el front que duplican reglas de negocio que deben vivir en la API.

Evidencia de hecho

Marca la práctica en la UI (interfaz de usuario) solo si existe esto (o equivalente claro):

P1 — 3 patrones: código + tests en projects/m14-patrones/src/ y ADRs en projects/m14-patrones/adr/.
P2 — Repo/Service: archivos *Repository* / *Service* (o rutas equivalentes documentadas en README).
P3 — Refactor: projects/m14-patrones/refactor-notas.md + evidencia en git (commits o diff).
Proyecto — ≥5 patrones: projects/m14-patrones/README.md índice + ADRs justificando cada uno.

Criterios de dominio

5 patrones aplicados con justificación escrita y enlace al código.
Explicas un patrón que rechazaste para Agenda Ops y por qué.
Los tests cubren el comportamiento público, no detalles internos frágiles.
Repository no filtra SQL (lenguaje de consulta estructurado) al dominio.