event-sourcing – ¿Qué viene primero: el evento o el cambio?

Pregunta:

He estado investigando Event Sourcing y parece que hay dos filosofías ocultas en lo que he leído. La diferencia central es si los actores del sistema son proactivos , primero realizan cambios y publican eventos en función de lo que han hecho, o si son reactivos , consumen eventos y actualizan los datos en función de esos eventos.

Sin embargo, el primero no es realmente Event Sourcing , ¿verdad? Los eventos no son la fuente del cambio, sino solo un registro de cambio. Eso es solo un registro basado en eventos que se puede usar para reconstruir los datos más tarde. Cuando reconstruyes el registro, estás usando un código diferente al que ejecutaste en primer lugar; en la ejecución original, envía un evento que lee la segunda vez. Además de todo eso, debe introducir comandos para activar esos cambios, que deben enviarse directamente al consumidor, lo que provoca un enlace más estricto.

Mientras tanto, el estilo "reactivo" revierte todas esas preocupaciones. Dado que cada cambio es una reacción a un evento, básicamente no hay diferencia entre escuchar el sistema "en vivo" mientras se enciende y escuchar una repetición en algún momento posterior. No hay necesidad de "comandos" explícitos, porque a los servicios no se les dice qué hacer. Más bien, están a cargo de mantener la coherencia frente a los eventos que ocurren en otros lugares y de notificar a otros sobre sus propios eventos. La otra cara de esto es una inversión de control: en lugar de conocer otros servicios / agregados por lo que se les puede decir qué hacer, que acaba de transmitir su evento al sistema y dejar que ellos responden de acuerdo a sus reglas. La única desventaja comparativa que veo es que debe ignorar explícitamente los mensajes nuevos al reproducir mensajes antiguos , pero eso se puede hacer con configuración / banderas.

Y, sin embargo, muchas guías y productos parecen respaldar un estilo proactivo. Por ejemplo, Event Store espera que los eventos se dividan en transmisiones según su objetivo , lo que significa que solo hay un objetivo por evento, como si lo estuviera enviando a un solo objetivo designado (lo que lo convierte en un comando glorificado) O porque el "objetivo" es en realidad solo la fuente que registra la acción que realizó.

Debe haber un vacío en mi comprensión, pero después de una semana más o menos de leer no he encontrado una explicación bien fundamentada para esto. Supongo que de esto surgen dos preguntas:

  1. ¿Cuál de estos dos enfoques es realmente el abastecimiento de eventos?
  2. ¿Hay beneficios que el enfoque proactivo tiene sobre el enfoque reactivo que no he mencionado aquí?

Respuesta:

Recordatorio: no es culpa suya que esté confundido; la literatura apesta .

¿Cuál de estos dos enfoques es realmente el abastecimiento de eventos?

El "abastecimiento de eventos", como lo dicen Event Store, el proyecto Eventide y otros, significa almacenar el estado como un historial de eventos. El almacén de eventos reemplaza el RDBMS que normalmente usamos para recordar nuestro historial. El historial, como se representa en una tienda de eventos, es una secuencia de eventos que se adjunta solo y que describe cómo una entidad ha cambiado con el tiempo.

Cuando reconstruyes el registro, estás usando un código diferente al que ejecutaste en primer lugar; en la ejecución original, envía un evento que lee la segunda vez.

Algo así, pero no de una manera que sea significativamente diferente de cómo hacemos las cosas en un mundo relacional.

En el mundo de un O / RM, ¿cómo recordamos dónde estamos? Normalmente, cuando llega nueva información, cargamos nuestra propia memoria desde la base de datos, integramos la nueva información y luego almacenamos nuestra nueva memoria en la base de datos (reemplazando la antigua). Se carga la memoria antigua, se calcula la nueva. Almacenamos la nueva memoria, y la próxima vez que la necesitemos, esa memoria se cargará.

Con el origen de eventos, este protocolo básico no se modifica; la diferencia significativa es que no reemplazamos la memoria anterior, sino que le agregamos nuevos cambios.

En términos de Pat Helland, el abastecimiento de eventos se trata de datos internos ; cómo el modelo de dominio en el pasado comparte información con el "mismo" modelo de dominio en el futuro.

el estilo "reactivo" revierte todas esas preocupaciones … No hay necesidad de "comandos" explícitos, porque a los servicios no se les dice qué hacer

No es una diferencia de la que valga la pena preocuparse. Los mensajes llegan, el modelo de dominio cambia, los mensajes se van. No importa mucho si etiqueta esos mensajes como comandos o eventos.

  • manejar (Evento) es un comando
  • CommandReceived es un evento

Puede introducir distinciones semánticas para separar los mensajes que se propagan hacia la autoridad (comandos) de los que se extienden desde la autoridad (eventos), pero desde la perspectiva del dominio, lo interesante es la información que contienen los mensajes, y cómo cambia el modelo de dominio en respuesta a esa información, no qué patrón creemos que se adapta mejor al mensaje.

Una idea que puede ayudar en todo esto es tener en cuenta que el origen de eventos proviene de una tradición de modelado de dominio, lo que significa que estamos administrando muchas pequeñas máquinas de estado que tienen sus propios datos privados para rastrear en qué estado se encuentran ahora, y su propia lógica de dominio para calcular en qué estado deberían estar a continuación. Piense en "diga, no pregunte": introducimos nueva información en el modelo de dominio y éste decide por sí mismo en qué estado debería estar ahora.

¿Un servicio le dice a otro qué hacer, o el primero simplemente anuncia lo que hizo y el segundo reacciona?

Esta es su confusión clave aquí mismo: esta es una pregunta sobre un patrón de comunicación. No tiene nada que ver con el origen de eventos , que es un patrón de representación de datos.

La más común (o al menos, la más comúnmente aprobada, también conocida como "mejores prácticas") es que los servicios comparten información con cero o más suscriptores; es decir, los mensajes se distribuyen en abanico. El servicio de origen publica un mensaje y los suscriptores reaccionan a él, o no, como mejor les parezca.

(La principal ventaja aquí es que puede agregar / eliminar suscriptores sin implementar una nueva copia del servicio de origen).

El mecanismo de intercambio de información entre servicios es una preocupación separada (una decisión de diseño separada) de la disposición de la información dentro de un servicio.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım