../constitution/founding-constitution.md
Traducción. Autoritativo: ../../adr/adr-004-transactional-outbox.md.
⚠️ Reconstruido a partir del material que tenemos, no recuperado. Etiquetas: [derived] tiene
respaldo en el repositorio · [inferred] es deducido · [proposed] es un hueco que llené.
Contexto
Un comando que cambia estado y después publica un evento tiene dos modos de falla que corrompen el sistema: la publicación falla y el evento se pierde, o la publicación tiene éxito, la transacción revierte, y el evento es una mentira. Ninguno es aceptable cuando el evento acredita puntos o envía un correo. [inferred]Decisión
Los eventos de dominio se escriben en un outbox transaccional dentro de la transacción del comando, y un relay los publica después. [derived] La publicación directa desde código de aplicación está prohibida. Un solo flujo de eventos alimenta seis consumidores: realtime, webhooks salientes, notificaciones, invalidación de caché, medición, e indexación de búsqueda o analítica. [inferred] — el material nombra “seis consumidores” repetidamente y nombra los primeros cinco; el sexto es reconstrucción mía. Los consumidores son idempotentes. La entrega at-least-once es el contrato, exactly-once no se ofrece, y todo consumidor está escrito para sobrevivir a ver un mensaje dos veces. [derived]Consecuencias
- Un evento existe si y solo si existe el cambio de estado que describe. Esa propiedad es lo que hace razonable a todo el sistema.
- Agregar un consumidor es aditivo y no toca ningún productor. − Los eventos se publican eventualmente, no al instante. Los presupuestos de latencia lo consideran. − El outbox es una tabla caliente y candidata a particionamiento con volumen.