Nivel 3 · 30 min

Patrones Arquitectónicos

Los patrones arquitectónicos operan a un nivel más alto que los patrones GoF — organizan componentes enteros, no solo clases. Los más relevantes para arquitectos senior son: Repository, Event Bus, CQRS y Saga. Aparecen constantemente en sistemas distribuidos y microservicios.

Repository Pattern

Repository actúa como una colección en memoria de objetos de dominio, ocultando los detalles de persistencia. El dominio trabaja con interfaces de repositorio (OrderRepository, UserRepository); la infraestructura implementa con JPA, MongoDB, etc. Ventajas: testeable (podés usar un repositorio in-memory en tests), intercambiable (podés migrar de MySQL a PostgreSQL sin tocar el dominio), desacoplado (DIP — la lógica de negocio no depende de Hibernate).

Event Bus

Event Bus implementa comunicación desacoplada publish/subscribe. Los productores publican eventos; los consumidores se suscriben por tipo. A diferencia del Observer puro (dependencia directa), el Event Bus introduce un broker central. Esto permite agregar consumidores sin modificar productores (OCP). Implementaciones: Spring ApplicationEventPublisher (in-process), Kafka, RabbitMQ (cross-process). Los eventos deben ser inmutables y auto-descriptivos.

CQRS y Saga en arquitectura

CQRS (Command Query Responsibility Segregation) separa las operaciones de escritura (Commands) de las de lectura (Queries). Los comandos mutan estado; las queries solo leen. Permite optimizar las rutas de lectura y escritura independientemente — distinto modelo de datos para leer y para escribir. Saga coordina transacciones distribuidas en microservicios — cada microservicio completa su transacción local y publica eventos para el siguiente paso, con compensaciones si algo falla.

Puntos clave

Repository abstrae el almacenamiento — el dominio habla de colecciones de entidades, no de SQL ni de colecciones Mongo.
Event Bus desacopla productores de consumidores en tiempo y espacio — producción y consumo pueden escalar independientemente.
CQRS admite que lectura y escritura son cargas de trabajo distintas — permitile a cada una optimizarse por separado.

Code example

// Repository: dominio desacoplado de persistencia
interface OrderRepository {
  Order findById(OrderId id);
  void save(Order order);
  List<Order> findByCustomer(CustomerId cid);
}
// En tests: InMemoryOrderRepository
// En produccion: JpaOrderRepository