📡
Arquitectura orientada a eventos (EDA)
Los servicios publican hechos que ya ocurrieron (eventos) en lugar de coordinar todo con llamadas síncronas. Los consumidores reaccionan de forma asíncrona y desacoplada: pueden estar caídos y recuperarse, escalar por separado y evolucionar contratos con reglas claras. No sustituye al REST/gRPC donde el flujo pide respuesta inmediata; convive con ellos.
01Domain event vs integration event
🏠
DENTRO DEL BOUNDED CONTEXT
Domain event
Ubiquitous LanguageModelo ricoInvariantes locales
Representa algo relevante que ocurrió en el dominio según el lenguaje del equipo (p. ej. OrderPlaced). Suele usarse dentro del mismo contexto o para sagas/coreografía si el nombre y la carga siguen siendo del dominio.
Criterio práctico: si cambias el nombre del evento y el equipo de negocio deja de entenderlo, probablemente no es un buen nombre de dominio.
🔌
CRUCE DE FRONTERA
Integration event
Contrato establePayload mínimo necesarioSchema explícito
Contrato pensado para que otro equipo o sistema consuma sin conocer tu modelo interno. Suele ser más estable, versionado y con campos pensados para compatibilidad hacia atrás (Avro/JSON Schema/Protobuf).
Mapeo típico: el dominio emite algo interno → un componente traduce a un integration event publicado en el bus (a veces el mismo tipo con capas distintas).
02Notification vs event-carried state transfer
Dos formas de informar a otros contextos
NOTIFICATION
El evento dice qué pasó y un ID; el consumidor debe consultar una API o su propia vista si necesita más datos. Menos datos en el bus, más acoplamiento temporal y más carga en lecturas downstream.
{ "type": "OrderPlaced", "orderId": "42" }
EVENT-CARRIED STATE TRANSFER (ECST)
El evento lleva la porción de estado que el consumidor necesita para actualizar su copia local (read model, cache). Más bytes en el bus, menos llamadas de ida y vuelta, ideal para vistas materializadas y reporting.
{ "orderId":"42","customerId":"c1",
"lines":[...], "total": 199.00 }
En reuniones de diseño suele decirse “¿notification o llevamos estado en el evento?” — ahí se está eligiendo entre menos payload + más queries vs más payload + menos dependencia síncrona.
03Contratos: schema, compatibilidad y versionado
📋
LO QUE ESPERA UN SENIOR EN UNA RFC
Contrato de evento explícito
Nombre del tipo (orders.OrderPlaced.v2), schema (Avro / JSON Schema / Protobuf), reglas de compatibilidad: solo añadir campos opcionales en minor, cambios breaking en major, política de deprecación. Los consumidores deben poder ignorar campos desconocidos (tolerant reader).
| Cambio | Típicamente compatible | Breaking |
|---|
| Nuevo campo opcional | Sí, si los lectores son tolerantes | — |
| Renombrar campo sin alias | No | Sí |
| Cambiar semántica del mismo campo | Riesgo alto | Casi siempre |
El bus no “arregla” contratos mal definidos: sin versionado acordado, cada despliegue es una ruleta de integración.
04Bounded context y límites del evento
Quién publica y quién interpreta
Contexto A
dueño del agregado
publica →
Topic / stream
contrato compartido
suscribe →
Contexto B
proyección / proceso
Un evento “global” sin dueño claro tiende al caos. El equipo dueño del agregado define el significado; los consumidores adaptan (translator / ACL) si su modelo difiere. Antipatrón: un topic donde cualquier servicio publica el mismo tipo de mensaje sin gobierno.