Llega un momento en toda aplicación en crecimiento donde un simple caso de uso empieza a convertirse en una cadena de responsabilidades difícil de mantener.
Imagina el proceso de registro de usuarios.
Al principio parece sencillo:
await userRepository.create(user);
Meses después, el mismo flujo termina haciendo algo parecido a esto:
await userRepository.create(user);
await emailService.sendWelcomeEmail(user);
await auditService.registerUserCreation(user);
await analyticsService.trackNewUser(user);
await crmService.createContact(user);
await notificationService.notifyAdmins(user);
El problema no es el código.
El problema es que tu módulo de usuarios ahora conoce demasiadas cosas.
Sabe cómo enviar correos.
Sabe cómo registrar auditorías.
Sabe cómo actualizar métricas.
Sabe cómo integrarse con sistemas externos.
Cada nueva integración aumenta el acoplamiento.
Cada nuevo requerimiento obliga a modificar código que ya funcionaba.
Y eventualmente algo tan simple como registrar un usuario se convierte en una operación de alto riesgo.
Aquí es donde entra Event-Driven Architecture.
El problema real: dependencias invisibles
Cuando analizamos sistemas que se vuelven difíciles de mantener, normalmente encontramos el mismo patrón:
UserService
├── EmailService
├── AuditService
├── AnalyticsService
├── CRMService
└── NotificationService
Cada dependencia adicional aumenta:
- Complejidad
- Acoplamiento
- Tiempo de pruebas
- Riesgo de regresiones
La consecuencia es que un cambio aparentemente pequeño termina afectando múltiples áreas del sistema.
La idea detrás de Event-Driven Architecture
En lugar de ejecutar todas las acciones directamente, el módulo publica un evento.
UserService
│
▼
UserCreatedEvent
│
┌────┼────┬─────┐
▼ ▼ ▼ ▼
Email Audit CRM Analytics
El servicio ya no necesita conocer quién consume el evento.
Solo comunica algo que ocurrió.
this.eventBus.publish(
new UserCreatedEvent(user.id, user.email),
);
Nada más.
Los eventos representan hechos
Un error común es modelar eventos como comandos.
Mal:
SendWelcomeEmailEvent
Bien:
UserCreatedEvent
La diferencia es importante.
Los eventos describen algo que ya ocurrió.
No expresan una intención.
Piensa en ellos como hechos del negocio.
UserCreatedEvent
OrderPaidEvent
InvoiceGeneratedEvent
SubscriptionCanceledEvent
Implementándolo en NestJS
NestJS incluye soporte nativo para eventos mediante CQRS.
Definimos el evento:
export class UserCreatedEvent {
constructor(
public readonly userId: string,
public readonly email: string,
) {}
}
Publicamos el evento:
this.eventBus.publish(
new UserCreatedEvent(
user.id,
user.email,
),
);
Creamos un handler:
@EventsHandler(UserCreatedEvent)
export class SendWelcomeEmailHandler
implements IEventHandler<UserCreatedEvent>
{
async handle(event: UserCreatedEvent) {
await this.emailService.sendWelcomeEmail(
event.email,
);
}
}
Ahora el módulo de usuarios ya no sabe nada sobre correos electrónicos.
Un evento, múltiples consumidores
Esta es una de las ventajas más importantes.
Un mismo evento puede ser consumido por varios módulos.
UserCreatedEvent
├── SendWelcomeEmailHandler
├── RegisterAuditHandler
├── SyncCRMHandler
└── GenerateMetricsHandler
Y el productor no necesita modificarse.
¿Cuándo usar eventos?
No todo debe convertirse en un evento.
Los eventos son especialmente útiles cuando:
- Existen efectos secundarios.
- Hay múltiples consumidores.
- Los módulos evolucionan de forma independiente.
- El proceso puede ejecutarse de forma asíncrona.
Por ejemplo:
✅ Registro de usuarios
✅ Creación de órdenes
✅ Generación de facturas
✅ Actualización de inventario
✅ Notificaciones
¿Cuándo NO usar eventos?
Si una operación es estrictamente necesaria para completar una transacción:
CreateOrder
└── ValidateStock
No la conviertas en evento.
Forma parte del flujo principal.
Los eventos son excelentes para desacoplar.
No son una excusa para ocultar lógica crítica.
Lo que ganamos en la práctica
| Beneficio |
Impacto |
| Menor acoplamiento |
Menos cambios cruzados |
| Escalabilidad |
Nuevos consumidores sin tocar el productor |
| Mantenibilidad |
Código más simple |
| Reutilización |
Un evento alimenta múltiples procesos |
| Evolución |
Integraciones independientes |
Un patrón que encaja perfectamente con Arquitectura Hexagonal
Si ya aplicas Arquitectura Hexagonal, los eventos encajan de forma natural.
El dominio genera eventos.
La aplicación los publica.
Los adaptadores reaccionan.
Esto mantiene el núcleo de negocio limpio y libre de dependencias externas.
Para cerrar
Muchos equipos intentan resolver problemas de escalabilidad agregando más servicios.
La mayoría de las veces el problema no es la cantidad de servicios.
Es la cantidad de dependencias entre ellos.
Event-Driven Architecture permite que los módulos colaboren sin conocerse.
Y cuando un sistema deja de depender de llamadas directas para cada integración, la velocidad de desarrollo aumenta y el mantenimiento deja de convertirse en una pesadilla.
Si tu UserService envía correos, registra auditorías, actualiza métricas y sincroniza sistemas externos, probablemente no necesitas otro servicio.
Probablemente necesitas eventos.
