Un patrón es un nombre para una respuesta, no una regla

En el ajedrez no reinventás la apertura en cada partida. Reconocés «esto es una Siciliana» y ya sabés hacia dónde suele llevar.

Patrón de arquitectura (architectural pattern) = problema que se repite + forma probada de resolverlo + precio conocido. Cuando decís «los servicios necesitan reaccionar a lo que pasa en otro lado», eso ya es un problema resuelto y con nombre — el patrón Event-driven architecture. Conocer el catálogo significa dejar de inventar y empezar a elegir.

Patrones de arquitectura ≠ patrones de diseño

Un patrón de diseño es cómo acomodás los muebles en una habitación. Un patrón de arquitectura es el plano de toda la casa.

Los patrones de diseño (design patterns) — Factory, Observer, Strategy — viven dentro del código de un módulo. Los patrones de arquitectura deciden qué «cajas» grandes hay en el sistema y qué líneas las unen: qué se despliega por separado, quién le habla a quién, dónde viven los datos. Este curso es sobre los planos, no sobre los muebles.

Mapa: 17 patrones en seis grupos

Un mapa del metro: primero ves las líneas enteras, después recorrés las estaciones.

Todos los patrones del curso se dividen en seis grupos. Cada grupo responde su propia pregunta: cómo estructurar una aplicación, hacia dónde apuntan las dependencias, cómo partir el sistema, cómo se comunican las piezas, cómo guardar la verdad en los datos y qué formas hacen falta para problemas raros.

Cómo leer cada patrón

Un pasaporte: los mismos campos para todos, por eso es fácil compararlos.

Cada patrón de acá en adelante tiene lo mismo: nombre en inglés (aprendetelo — es el término), una imagen de la vida real, un diagrama y una ficha con campos: problema (qué duele), idea (cómo lo resuelve), ejemplo, coste (qué pagás), cuándo usarlo y relaciones con otros patrones. La regla principal: no existe el mejor patrón — existe el que encaja, y cada uno tiene una factura que hay que leer antes de firmarla.

Layered Architecture — arquitectura en capas

Un restaurante: el salón toma los pedidos, la cocina cocina, la despensa almacena. El mozo no cocina, el chef no baja al sótano — cada uno habla solo con la capa de abajo.

El patrón más común. El código se parte en capas (layers) horizontales, y la request las atraviesa de arriba hacia abajo. Cada capa conoce solo a la capa de abajo.

Modular Monolith — monolith modular

Un edificio de departamentos: un solo techo y una sola entrada, pero cada departamento tiene sus propias paredes y su puerta. No atravesás el dormitorio del vecino para llegar a la escalera.

Sigue siendo una sola aplicación, pero por dentro está partida en módulos (modules) según el negocio — facturación, catálogo, cuentas. Los módulos hablan solo a través de una interfaz pública y no meten la mano en las tablas ajenas.

MVC / MVVM — mantené la pantalla lejos del cerebro

Un teatro: el guion, los actores con el director y el escenario con las luces son trabajos distintos. Cambiás la escenografía sin reescribir la obra.

Estos patrones ponen una pared entre la interfaz y los datos con sus reglas, para que un cambio en cómo algo se ve no rompa lo que hace.

Hexagonal Architecture — puertos y adaptadores

Una consola de juegos con puertos estándar. Al juego no le importa qué enchufaste — un joystick, un volante o un palo de arcade; solo lee «input».

El núcleo con la lógica de negocio declara puertos (ports) — interfaces como «guardar un pedido» o «cobrar». Afuera, los adaptadores (adapters) implementan esos puertos para una tecnología concreta. Los driving adapters llaman al núcleo (API HTTP, CLI, tests), los driven adapters son llamados por el núcleo (base de datos, pasarela de pagos, email).

Clean / Onion Architecture — las dependencias apuntan hacia adentro

Una cebolla: el corazón en el centro, capas alrededor. Podés pelar la piel sin dañar el corazón — y el corazón no depende de la piel.

El mismo principio en forma de círculos. En el centro, las entidades (entities); alrededor, los casos de uso (use cases); después, los adaptadores; afuera, los frameworks y la base de datos. La regla principal — la dependency rule: cada flecha de dependencia apunta hacia el centro.

Microservices — microservicios

Un patio de comidas: cada local tiene su cocina, su menú y su caja. Si se llena la pizzería, ponen dos cocineros más; el de ensaladas no lo necesita.

El sistema se parte en servicios (services) chicos: cada uno es dueño de una capacidad de negocio y de su propia base de datos, y se despliega y escala por separado. Los servicios hablan por la red — HTTP o un bus de mensajes.

Serverless — funciones a demanda

En lugar de tener un auto parado sin uso, llamás un taxi y pagás solo mientras corre el taxímetro.

Escribís funciones (functions) chicas, y la nube las corre cuando llega un evento, las escala sola de cero a miles de copias y de vuelta, y te cobra por cada ejecución.

Request–Response — preguntá y esperá

Pedir en un mostrador: preguntás, te quedás parado, recibís tu café — y recién ahí seguís.

El cliente manda una request y espera la response. Es comunicación síncrona: REST, gRPC, una query a la base de datos.

Event-driven Architecture — anunciá y que los oyentes reaccionen

Una redacción: sale una noticia y deportes, clima y avisos reaccionan solos. El que anuncia no los espera y ni siquiera sabe quién escucha.

Un componente no llama a los demás: publica un evento (event) — un hecho que ya pasó: «OrderPlaced». Al que le interesa, está suscrito y reacciona. Dos variantes: broker (los eventos circulan libremente) y mediator (un coordinador corre los pasos en orden).

Message Queue y Pub/Sub — un correo entre las piezas

El correo guarda la carta hasta que el destinatario esté listo. La dejás en el buzón y te vas; la lee cuando se despierta.

Una cola de mensajes (message queue) o un broker pub/sub se pone entre emisor y receptor para que no tengan que estar online al mismo tiempo. En una cola, cada mensaje lo toma un solo worker; en pub/sub, cada mensaje les llega a todos los suscriptores.

Pipe-and-Filter — una línea de montaje para datos

Una línea de embotellado: lavar, llenar, tapar, etiquetar. Cada estación hace una cosa y pasa la botella.

Los datos fluyen por una cadena de pasos independientes — filtros (filters) unidos por tuberías (pipes). Cada filtro hace una sola transformación.

CQRS — modelos separados para escribir y leer

Una biblioteca tiene un catálogo rápido para buscar y una trastienda donde los libros se acomodan en los estantes. Buscar está optimizado para una cosa; guardar, para otra.

CQRS (Command Query Responsibility Segregation) separa el modelo de escritura — los comandos (commands) que cambian los datos — del modelo de lectura — las queries que los traen. Cada uno se puede optimizar y escalar por separado.

Event Sourcing — guardá la historia, no el estado

Un banco no guarda solo tu saldo, sino cada depósito y cada extracción. El saldo es solo la suma. Si lo perdés, lo recalculás desde el libro mayor.

En lugar de sobrescribir el estado actual, guardás un flujo de eventos (event log), agregando siempre al final. El estado actual se obtiene reproduciendo (replay) los eventos.

Saga — una operación larga que podés deshacer

Reservás un viaje: vuelo, hotel, auto. Si se cae el auto, cancelás el hotel y el vuelo. No hay un único botón «deshacer todo»; vas desandando paso a paso.

Cuando una acción de negocio pasa por varios servicios, cada uno con su base de datos, no se puede hacer una sola transacción común. Una Saga es una cadena de transacciones locales; si un paso falla, se corren acciones compensatorias (compensations) que deshacen los pasos anteriores.

Microkernel — un núcleo chico y plug-ins

Un taladro: un solo motor y una docena de puntas. El taladro es el mismo; cambiás la punta según el trabajo.

Un núcleo (core) mínimo da la base, y todo lo demás llega como plug-ins que se enchufan al núcleo y no dependen unos de otros.

Space-based Architecture — datos en memoria, sin cuello de botella

Un estadio con veinte boleterías, cada una con su propia copia del mapa de butacas — en lugar de una sola taquilla con una fila enorme.

Cuando una única base de datos se vuelve el cuello de botella bajo una carga enorme, el trabajo se reparte entre muchas processing units, cada una con los datos en memoria. La memoria se sincroniza entre ellas (data grid), y los datos se escriben en la base más tarde, de forma asíncrona.

Peer-to-Peer — sin centro

Una comida a la canasta: cada uno es a la vez cocinero e invitado. Sin restaurante, sin mozo — el grupo se alimenta solo.

Los nodos — peers — hablan directamente entre sí, sin servidor central. Cada uno es a la vez cliente y servidor.

Los patrones están relacionados entre sí

Una casa usa a la vez muros de carga, plomería y cableado — no «el único patrón de construcción verdadero».

Los patrones no viven solos. El monolith modular crece hacia microservicios; los microservicios necesitan eventos, colas y sagas; Hexagonal y Clean son la misma idea; CQRS y Event Sourcing andan en pareja.

Un sistema real puede ser un monolith modular por fuera, Clean Architecture en cada módulo, Request–Response para la interfaz, eventos para los efectos secundarios lentos y una cola delante del job pesado. La pregunta no es «qué patrón» sino «qué patrones, y dónde».

Empezá con la forma más simple

No colás los cimientos de un estadio para construir una cabaña.

Casi todo sistema debería empezar como Modular Monolith y ganarse su complejidad. Microservices, CQRS, Event Sourcing, Space-based — son respuestas a problemas de escala y de tamaño de equipo que quizás nunca tengas. El sistema distribuido más barato es el que no construiste.