Contratos de eventos entre contextos delimitados

Un evento compartido parece la integración más barata posible. Un equipo publica, otro consume, nadie bloquea a nadie. Sigue siendo barato hasta la primera deriva de significado — y el significado deriva en silencio, porque el esquema sigue validando.

El esquema es la mitad pequeña

OrderPlaced { orderId, customerId, total, currency } le dice al consumidor qué campos llegan. No le dice:

• Si total incluye impuestos, y en qué jurisdicción se decidió
• Si el pedido todavía puede cancelarse cuando esto se emite
• Si el mismo orderId puede aparecer dos veces
• Qué hará el productor si el consumidor está caído una hora

Cada uno de esos puntos es una decisión que alguien tomó. Si no está escrita junto al esquema, cada consumidor adivinará, y adivinarán distinto.

Escriba las tres cosas que un esquema no puede decir

Cuándo se emite. No «al crear el pedido»: la transición exacta. Tras autorizarse el pago y antes de notificar la preparación. Un consumidor que lo suponga antes construirá una función sobre un estado que aún no existe.

Qué promete sobre la entrega. Al menos una vez, como mucho una vez, o exactamente una vez en el único sentido real: manejo idempotente en el consumidor. Diga cuál, y diga cuál es la clave de deduplicación.

Qué puede cambiar. Añadir un campo opcional es seguro. Estrechar un enum no lo es, y en un diff se parecen. Nombre la regla de compatibilidad para que un revisor pueda aplicarla.

Pruebe la frontera desde los dos lados

Lo más útil que puede hacer un productor es publicar una prueba de contrato que el consumidor ejecute en su propia cadena. No un entorno de integración compartido: eso le dice que los dos sistemas funcionaron una vez, ese día, con esos datos.

productor : publica payloads de ejemplo para cada versión que soporta
consumidor: comprueba que su handler los acepta y produce el estado esperado
CI        : ambos se ejecutan en cada cambio, en los dos repositorios

Cuando un productor rompe la compatibilidad, falla en su cadena, con el nombre del consumidor que se va a romper. Es una conversación antes de un despliegue en vez de un incidente después.

Versione el significado, no solo el payload

Un campo añadido es una versión nueva del payload. Una regla cambiada — impuestos ahora fuera de total — es una versión nueva del significado, y eso pide un tipo de evento nuevo, no un campo nuevo. Un consumidor no puede detectar un cambio semántico inspeccionando un mensaje: por eso mismo tiene que verse en el nombre.

Los equipos que siguen siendo rápidos no son los que tienen menos contratos. Son aquellos cuyos contratos dicen lo suficiente como para que nadie tenga que leer el código del productor para usarlos.