¿Dónde almacenar eventos en un sistema distribuido que utiliza el abastecimiento de eventos?

Question

Dado que tiene varios sistemas, que están integrados por eventos, y todos ellos están utilizando el abastecimiento de eventos. ¿Dónde almacenas los eventos?

En mi caso tengo tres sistemas:

• un sitio web, que es una tienda de
• Un backend para la Web para gestionar los clientes, productos, etc
• Un sistema de contabilidad

Cada vez que ocurre un evento de dominio en uno de esos sistemas, el evento se publica y puede ser procesado por los otros sistemas. Todos los sistemas usan fuentes de eventos.

Me pregunto dónde guardarías los eventos. Por supuesto, cada sistema tiene que almacenar todos los eventos que procesó porque está utilizando fuentes de eventos y, por lo tanto, depende de los eventos que procesó una vez.

Pero, ¿qué pasa con los otros eventos que no eran necesarios y por lo tanto el sistema no se suscribió? Estoy luchando con el hecho de que los requisitos pueden cambiar, de modo que un sistema tendría que procesar eventos del pasado que no persistieron. ¿De dónde obtendrían estos eventos si el sistema necesitara procesar eventos que no se suscribieron cuando ocurrieron?

Creo que hay una gran diferencia para los sistemas que no usan el abastecimiento de eventos en este momento. Si tiene que implementar una característica en un sistema A que depende de los datos, que no está disponible en A, sino en otro sistema B, y su estado actual persistente mediante una herramienta ORM como NHibernate, puede simplemente importar esos datos de A a B Dado que un sistema, que utiliza el abastecimiento de eventos, depende de los eventos para llegar a su estado actual, debe importar todos los eventos que perdió en el pasado pero que ahora necesita.

Para mí hay algunos enfoques diferentes para este problema.

1. Cada sistema guarda todos los eventos que se publican. Esto le da la posibilidad de volver a publicar los eventos si es necesario o importarlos a otro sistema.
2. Cada sistema guarda todos los eventos que suceden, incluso aquellos que no necesitan procesarse (aún).
3. Todos los eventos de todos los sistemas se almacenan en el registro central de eventos. Si necesita procesar un evento que sucedió en el pasado pero no se suscribió, puede importarlo desde aquí.

¿Cómo manejas una situación como esta? ¿Dónde guardas tus eventos?

Editar

Gracias Roy Dictus por su respuesta. Todavía no estoy seguro de cómo manejar la siguiente situación:

El sitio web publica los eventos CustomerRegistered, CustomerPurchasedProduct y CustomerMarkedProductAsFavorite. En la versión actual del servidor, los clientes deben mostrarse y deben mostrarse sus compras. Lo que un cliente marcó como favorito no es de interés en esa versión del sistema. Por lo tanto, el backend solo se suscribió a CustomerRegistered y CustomerCompradoProduct.

Ahora el departamento de marketing también quiere que la información sobre los productos favoritos se muestre en la página de detalles del cliente. Como el servidor no se suscribió a CustomerMarkedProductAsFavorite, esta información no está disponible en el back-end. ¿De dónde obtengo esa información?

Answer 1

1. Cada sistema almacena sus propios eventos. Cada sistema es su propio sistema CQRS, o al menos su propio servicio independiente, y por lo tanto es responsable de sus propios datos.
2. Cada sistema también publica su evento en un bus de servicio. Este bus de servicio determina dónde guarda estos eventos. Usualmente está en un sistema de colas transaccionales.
3. Cada sistema se suscribe a los eventos externos que consume. No almacena estos eventos entrantes, solo sus propios eventos que resultan de ellos. Cuando consume un evento entrante, el bus de servicio sabe que puede eliminar el evento de la cola entrante de ese servicio.

EDITAR para dar cabida a su pregunta adicional:

Si otra aplicación de repente se vuelve interesado en obtener información adicional, se ha de añadir detectores para los eventos que ahora está interesada en

Además, todos. las fuentes de estos eventos pueden luego reproducir esos eventos. La reproducción es una poderosa característica de los sistemas basados ​​en eventos que permite tales escenarios. Por lo tanto, las fuentes del evento solo reproducen los eventos seleccionados (por ejemplo, todos los eventos CustomerMarkedItemAsFavorite de los últimos 6 meses). Los sistemas que ya han consumido estos eventos deben reconocer que los eventos reproducidos son "antiguos" (es decir, los que ya se han procesado) e ignorarlos.

De esta forma, cualquier subsistema que se actualice para usar información adicional de los otros subsistemas puede obtener esa información y actualizarse en una sola operación por lotes.

Answer 2

WRT su edición: ¿Es realmente un requisito para acceder también a los datos históricos CustomerMarkedProductAsFavorite. Cambie el backend para suscribirse a los nuevos datos y luego siga adelante. Puede averiguar cómo rellenar los datos faltantes como un problema separado si realmente lo necesita.

Roy ya ha esbozado una arquitectura posible que garantizaría que tenga los datos CustomerCarkedProductAsFavorite para rellenar en el futuro.