Patrones de Diseño y Arquitectura

Las tres categorías GoF

Esta clase cubre los 7 patrones que probablemente uses esta semana, no los 23. El resto vive en los libros del bloque "Para profundizar".

Practica reconocer el patrón

Lee cada escenario, elige el patrón que mejor encaja y comprueba. Cubre el Ejercicio 8.1 al completo.

Para empezar con los patrones

Tres recursos suficientes para tener una base sólida antes de leer el libro original.

Factory

Centraliza la creación de objetosdetrás de una interfaz común, ocultando el new al resto del código.

interface Notificacion {

  enviar(mensaje: string): void;

}

class Email implements Notificacion { ... }

class SMS   implements Notificacion { ... }

class Push  implements Notificacion { ... }

class NotificacionFactory {

  static crear(tipo: "email"|"sms"|"push") {

    switch (tipo) {

      case "email": return new Email();

      case "sms":   return new SMS();

      case "push":  return new Push();

    }

  }

}

NotificacionFactory.crear("email").enviar("Hola");

Builder

Construye objetos complejos paso a paso, separando la construcción de la representación.

class QueryBuilder {

  private tabla = "";

  private condiciones: string[] = [];

  private campos: string[] = ["*"];

  private limite: number | null = null;

  from(t: string)        { this.tabla = t;          return this; }

  select(...c: string[]) { this.campos = c;          return this; }

  where(c: string)       { this.condiciones.push(c); return this; }

  limit(n: number)       { this.limite = n;          return this; }

  build(): string { /* arma el SQL */ }

}

new QueryBuilder()

  .from("usuarios")

  .select("nombre", "email")

  .where("edad > 18")

  .limit(10)

  .build();

Profundizar en creacionales

Cuidado con Singleton: tiene tantos defensores como detractores. Lee ambos lados.

Decorator

Envuelve un objeto añadiendo comportamiento sin cambiar su interfaz. Apilable: varios decoradores se componen en cualquier orden.

interface Notificador {

  enviar(msg: string): void;

}

class EmailNotificador implements Notificador {

  enviar(m) { sendEmail(m); }

}

class ConLog implements Notificador {

  constructor(private wrapped: Notificador) {}

  enviar(m) {

    console.log("→ enviando:", m);

    this.wrapped.enviar(m);

  }

}

// Apilar decoradores:

const n = new ConReintentos(

  new ConLog(

    new EmailNotificador()));

Facade

Ofrece una interfaz simple sobre un subsistema complejo. Esconde la coreografía interna y expone solo lo que el cliente necesita.

// Subsistema complejo (varios módulos)

import { stripe }     from "./payments";

import { inventario } from "./stock";

import { facturas }   from "./billing";

import { emailer }    from "./email";

// Facade: una sola puerta de entrada

export const tienda = {

  async comprar(usuario, items) {

    const cargo = await stripe.cobrar(...);

    await inventario.descontar(items);

    const pdf = await facturas.generar(cargo);

    await emailer.enviar(usuario, pdf);

    return { ok: true, cargo };

  }

};

// El controlador solo hace:

await tienda.comprar(req.user, req.body.items);

Profundizar en estructurales

Decorator, Facade, Adapter, Proxy y Composite componen el grupo. Estos recursos te dan ejemplos en TypeScript y comparativas entre patrones cercanos.

Observer en vivo

Suscribe y desuscribe listeners y dispara el evento. Verás que el emisor jamás se entera de quién está escuchando.

Esperando emisión...

Strategy

Encapsula algoritmos intercambiablesdetrás de una misma interfaz, para elegir uno u otro en tiempo de ejecución.

interface EstrategiaDescuento {

  calcular(precio: number): number;

}

class SinDescuento     { calcular(p) { return p; } }

class Porcentual       { /* p * (1-x/100) */ }

class BlackFriday      { /* condicional */ }

class Carrito {

  estrategia: EstrategiaDescuento;

  total() {

    return this.estrategia.calcular(this.subtotal());

  }

}

Cambia la estrategia, no el carrito

El carrito siempre llama a estrategia.calcular(). Alternar entre cuatro estrategias diferentes no cambia ni una línea del carrito.

              class SinDescuento implements EstrategiaDescuento {
            

                calcular(p: number) { return p; }
            

              }
            

              class Descuento10 implements EstrategiaDescuento {
            

                calcular(p: number) { return p * 0.9; }
            

              }
            

              class Descuento20 implements EstrategiaDescuento {
            

                calcular(p: number) { return p * 0.8; }
            

              }
            

              class BlackFriday implements EstrategiaDescuento {
            

                calcular(p: number) {
            

                  return p > 100 ? p * 0.5 : p * 0.7;
            

                }
            

              }
            

Profundizar en comportamiento

Observer y Strategy son la punta del iceberg. Command, State, Chain of Responsibility, Iterator, Mediator y Template Method completan el grupo.

Frontend: React, Next.js, TypeScript

Si llegaste hasta aquí, ya escribiste estos patrones decenas de veces. Ahora les pones nombre.

Backend: Express, Sequelize, JWT, Zod, Node

Los frameworks del backend están aún más cargados de patrones que el frontend: APIs encadenables, middlewares y drivers intercambiables.

Cuando una API de un framework "se siente bien", suele ser porque aplica el patrón correcto sin que tengas que pensarlo.

MVC — Modelo · Vista · Controlador

Separa la app en tres responsabilidades: datos,presentación yorquestación. La base de Express, Rails, Laravel y Spring.

// Controlador (orquesta)

const tareasController = {

  listar: async (req, res) => {

    const tareas = await Tarea.findAll();

    res.json(tareas);

  },

  crear: async (req, res) => {

    const t = await Tarea.create(req.body);

    res.status(201).json(t);

  }

};

// Rutas (vista de la API)

app.get ('/api/tareas', tareasController.listar);

app.post('/api/tareas', tareasController.crear);

Variantes de MVC: MVP y MVVM

Cuando la UI se vuelve compleja, MVC clásico se acorta. MVP yMVVM redistribuyen responsabilidades para que la vista sea más tonta y la lógica más testeable.

Clean Architecture

Capas concéntricas donde las dependencias apuntan hacia adentro. La lógica de negocio no sabe que existen ni Express ni Prisma.

┌──────────────────────────────────────────────┐

│  Frameworks & Drivers (Express, Prisma, …)   │

│  ┌────────────────────────────────────────┐  │

│  │  Adaptadores (Controllers, Repos, DTO) │  │

│  │  ┌──────────────────────────────────┐  │  │

│  │  │  Casos de uso (Application)      │  │  │

│  │  │  ┌────────────────────────────┐  │  │  │

│  │  │  │  Entidades (Domain rules)  │  │  │  │

│  │  │  └────────────────────────────┘  │  │  │

│  │  └──────────────────────────────────┘  │  │

│  └────────────────────────────────────────┘  │

└──────────────────────────────────────────────┘

Regla: las flechas de dependencia apuntan

siempre hacia adentro. Lo interno NO conoce

a lo externo (DIP — Dependency Inversion).

Hexagonal (Ports & Adapters)

Hermana de Clean Architecture, propuesta por Alistair Cockburn en 2005. La aplicación expone puertos (interfaces) y el mundo exterior se conecta mediante adaptersintercambiables.

        ┌────── REST adapter ──┐

        │      ┌──────────┐    │

CLI ────┼─[ port ]─│          │    │

        │          │   APP    │    │

Tests ──┼─[ port ]─│ (dominio │    │

        │          │  + casos │    │

GraphQL─┼─[ port ]─│   uso )  │    │

        │          └────┬─────┘    │

        └─[ port: Repository ]───┘

                  │

         ┌────────┼────────┐

         ▼        ▼        ▼

      Postgres  Mongo   InMemory

El dominio solo conoce puertos.

Los adapters son enchufables.

Monolito vs Microservicios

No es una cuestión de moda: es una decisión organizacional. Microservicios cambian un problema técnico (acoplamiento) por uno operativo (distribuir, observar, desplegar).

Profundizar en arquitectura

Los patrones son tácticos; la arquitectura es estratégica. Estos recursos te ayudan a entender la diferencia.

Refactor en vivo: Strategy + Observer

El código Antes es el del Ejercicio 8.4: un if/else con email y analytics duplicados. Alterna a Después y observa cómo Strategy y Observer separan responsabilidades.

function procesarPago(tipo, monto, datos) {

  if (tipo === "tarjeta") {

    if (datos.numero.length !== 16)

      return { exito: false, error: "Numero invalido" };

    console.log(`Cobrando $${monto} a tarjeta ${datos.numero}`);

    console.log(`Email: Pago de $${monto} con tarjeta`);

    console.log(`Analytics: pago_tarjeta, $${monto}`);

    return { exito: true, transaccion: "TXN-" + Date.now() };

  } else if (tipo === "paypal") {

    if (!datos.email.includes("@"))

      return { exito: false, error: "Email invalido" };

    console.log(`Cobrando $${monto} via PayPal a ${datos.email}`);

    console.log(`Email: Pago de $${monto} con PayPal`);

    console.log(`Analytics: pago_paypal, $${monto}`);

    return { exito: true, transaccion: "PP-" + Date.now() };

  }

}

// 1) Strategy — cada método encapsulado

class PagoTarjeta {

  validar(d) { return d.numero?.length === 16; }

  cobrar(monto, d) {

    return { id: "TXN-" + Date.now(), canal: "tarjeta", monto };

  }

}

class PagoPaypal {

  validar(d) { return d.email?.includes("@"); }

  cobrar(monto, d) {

    return { id: "PP-" + Date.now(), canal: "paypal", monto };

  }

}

// 2) Observer — notificaciones desacopladas

const bus = new EventEmitter();

bus.on("pago", (e) => emailService.confirmar(e));

bus.on("pago", (e) => analytics.track("pago", e));

// 3) Orquestador

function procesarPago(estrategia, monto, datos) {

  if (!estrategia.validar(datos))

    return { exito: false, error: "Datos invalidos" };

  const r = estrategia.cobrar(monto, datos);

  bus.emit("pago", r);

  return { exito: true, transaccion: r.id };

}

Ejecuta un pago para ver la traza...

Ejercicio 8.2: Implementar un Factory

Crea un sistema de formas geométricas usando Factory.

Ejercicio 8.3: Observer en la práctica

Sistema de notificaciones para una tienda online. Tres eventos, tres listeners independientes.

Simula el flujo completo: registro → compra → envío. Comprueba que cada listener se ejecuta solo cuando le corresponde.

Estructura sugerida

Cada carpeta tiene una sola razón para cambiar.

src/

├── routes/         (rutas Express)

├── controllers/    (HTTP → caso de uso)

├── services/       (lógica de negocio)

├── repositories/   (acceso a BD)

├── middleware/     (auth, validar, errors)

└── utils/          (helpers puros)

Criterios de evaluación