En cualquier sistema distribuido construido con Domain-Driven Design, un hecho del negocio que ocurre en un contexto delimitado debe viajar hasta otro contexto con su propio lenguaje y sus propias responsabilidades. Este artículo, parte de una serie sobre DDD, explica cómo diseñar ese contrato —denominado evento de integración— y cómo garantizar su entrega cuando un contexto debe notificar a otro.
El primer problema es el diseño del contrato. Publicar directamente un evento de dominio expone identificadores, value objects y detalles internos del modelo productor, obligando a cada consumidor a acoplarse a ese modelo y rompiendo refactorizados futuros. La alternativa es traducir el mismo hecho a un evento externo con un sobre (metadata + body) que contenga únicamente la información necesaria: identificadores estables, datos de ruteo, deduplicación y versionado, y un payload con los valores serializados que el consumidor necesita. El artículo ilustra la diferencia con un ejemplo en JSON en el que Ordering notifica a Fulfillment que un pedido está listo, omitiendo datos del cliente y empleando códigos de producto neutros.
El segundo problema es la entrega fiable. La mensajería asíncrona sobre infraestructura duradera (Apache Kafka, RabbitMQ o Azure Service Bus) permite que cada contexto procese trabajo a su ritmo, pero introduce riesgos de indisponibilidad, duplicación y ausencia de transacciones distribuidas. El texto distingue entre eventos de dominio y eventos de integración, advierte contra publicar streams de event sourcing o de Change Data Capture como contratos públicos, y recomienda usar esos flujos solo como fuente interna para derivar eventos de integración. También discute los patrones para decidir cuánta información incluir en el mensaje frente a dejar que el consumidor la consulte bajo demanda, un equilibrio que el artículo deja abierto para una entrega posterior.