El origen de eventos (origen de eventos, registro de eventos, generación de eventos) es un patrón arquitectónico poderoso en el que todos los cambios realizados en el estado de la aplicación se guardan en el orden en que ocurrieron. Estos registros sirven como fuente para obtener el estado actual y como pista de auditoría de lo que sucedió en la aplicación durante su vida útil. El abastecimiento de eventos facilita el cambio y la lectura de datos descentralizados. Esta arquitectura se escala bien y es adecuada para sistemas que ya están trabajando con el manejo de eventos o que desean migrar a dicha arquitectura.
¿Qué es el abastecimiento de eventos?
Los expertos en dominios generalmente describen sus sistemas como una colección de entidades , que son contenedores para almacenar estados y eventos que reflejan cambios en las entidades como resultado del procesamiento de datos de entrada en varios procesos comerciales. Los eventos a menudo se desencadenan por comandos provenientes de usuarios, procesos en segundo plano o integraciones con sistemas externos.
Básicamente, el abastecimiento de eventos se centra en eventos relacionados con cambios en el sistema.
Muchos patrones arquitectónicos ven las entidades como un concepto primario. Estas plantillas describen cómo guardarlas, cómo acceder a ellas y cómo modificarlas. Dentro de este estilo arquitectónico, los eventos suelen ser "laterales": son las consecuencias de entidades cambiantes.
Normalmente, estas arquitecturas se basan en un almacén de entidades, como una base de datos relacional o un almacén de documentos. Aunque los eventos pueden estar presentes en dicha arquitectura, en su esencia, no son un concepto principal y pueden separarse de las entidades con las que están asociados, así como esconderse detrás de capas de lógica empresarial.
Event Sourcing invierte este enfoque centrándose en la implementación de eventos: cómo se persisten y cómo se pueden utilizar para obtener el estado de una entidad. En este caso, la base de datos contendrá un registro secuencial de todos los eventos que ocurrieron durante la vida útil del sistema.
A continuación se muestra una comparación de Event Store con Entity Store (que se describe con más detalle a continuación):
El abastecimiento de eventos, utilizando eventos como el concepto arquitectónico principal, es también un paradigma de modelado de dominio que refleja mejor la visión del sistema del cliente. El diseño de sistemas con énfasis en eventos y registros de eventos proporciona los siguientes beneficios:
- , « » .
- (command/query responsibility), .
- , , , .
Event Sourcing
Veamos un ejemplo sencillo con una cuenta bancaria. Tendremos una entidad que representará una Cuenta Bancaria. Por simplicidad, crearemos solo una cuenta sin identificarla usando el número de cuenta o de cualquier otra manera. La cuenta mantendrá el saldo actual de fondos.
Dos comandos (comando) estarán disponibles para la cuenta : depositar dinero (depositar) y retirar dinero (retirar). Los comandos indicarán la cantidad a depositar o retirar. También definiremos una regla comercial que verifique que un comando de retiro solo se puede procesar si el monto solicitado es igual o menor que el saldo actual de la cuenta.
Con este enfoque, se pueden distinguir dos eventos (evento)- “Cuenta acreditada” y “Cuenta debitada”. Estos eventos contienen información sobre la cantidad que se ha depositado o retirado. Esto podría simplificarse a un solo evento con una suma positiva o negativa, pero en este ejemplo los dividiremos.
El siguiente diagrama muestra el modelo de datos.
Tenga en cuenta que los eventos son "tiempo pasado". Indican lo que sucedió en el sistema en el momento en que se escribieron y se guardan solo si el comando se procesó correctamente. Con este enfoque, se debe tener cuidado de no confundir comandos con eventos. Especialmente si se reflejan entre sí.
La secuencia de comandos puede verse así:
1.deposit {cantidad: 100} - depositar 100
2. retirar {cantidad: 80} - retirar 80
3. retirar {cantidad: 50} - retirar 50
La implementación más simple de Event Sourcing requiere un registro de eventos , que es simplemente una secuencia de eventos. Al procesar los comandos anteriores, obtiene dicho registro.
El tercer comando no se puede ejecutar porque la cantidad solicitada excede el saldo disponible.
Para obtener el saldo actual, el sistema debe procesar o "generar" eventos en el orden en que ocurren. Para nuestro ejemplo, podría verse así:
- cuenta bancaria {saldo actual: 0} (estado inicial)
cuenta bancaria {saldo actual: 0} (estado inicial) - bank account { current balance: 100 } (processed: Account Credited, +100)
{ : 100 } (: , +100) - bank account { current balance: 20 } (processed: Account Debited, -80)
{ : 20 } (: , -80)
El saldo actual se calcula mediante el procesamiento de todos los eventos hasta el momento actual. Dado que cada evento tiene una marca de tiempo implícita, es posible calcular el estado de la cuenta en cualquier momento procesando todos los eventos durante el período de tiempo requerido.
Este es un ejemplo completo (aunque trivial) de Event Sourcing. En un sistema real, lo más probable es que este ejemplo deba ampliarse.
Puede ser necesario guardar la secuencia de comandos para poder identificar cómo ocurrió el evento, así como crear un registro de eventos de error separado en el que registrar los comandos que no se completaron, para un mayor manejo de errores y mantener un historial completo de errores y errores. equipos fracasados.
Con el tiempo, a medida que aumenta el número de comandos, puede ser necesario mantener el saldo actual de la cuenta para que cuando se reciba un comando de retiro, no sea necesario procesar la lista completa de eventos para determinar si el comando se puede ejecutar (es decir, si la cuenta tiene fondos suficientes). Este es un ejemplo de una tienda derivada y es esencialmente lo mismo que una tienda de entidad.
A continuación se muestra cómo se verá la tienda de entidades para nuestro ejemplo después de procesar todos los comandos.
Obviamente, en comparación con una tienda de eventos completa, este es un ejemplo muy primitivo. Y esta es una de las razones por las que muchos desarrolladores solo usan la tienda de entidades. En este caso, el saldo de la cuenta corriente está disponible de inmediato y no es necesario procesar todos los eventos históricos.
Sin embargo, Event Sourcing no excluye las tiendas de entidades. A menudo, las tiendas de entidades también están presentes en proyectos de abastecimiento de eventos.
Fin de la primera parte.
