Lea la primera parte.
Características de la implementación de Event Sourcing
Desde un punto de vista técnico, Event Sourcing solo requiere una implementación de registro y registro de eventos.
En el caso más simple, se puede utilizar un archivo como almacenamiento de eventos, en el que se registra un evento separado en cada línea, o varios archivos, cuando cada evento se guarda en un archivo separado. Pero, por regla general, en sistemas grandes que exigen paralelismo y escalabilidad, se utilizan métodos de almacenamiento más fiables.
El registro de eventos es un patrón muy común que se utiliza junto con el intermediario de mensajes (middleware orientado a mensajes) y los sistemas de procesamiento de flujo de eventos. Un intermediario de mensajes, utilizado como registro de eventos, puede almacenar todo el historial de mensajes si es necesario.
Los modelos relacionales y documentales suelen centrarse en el modelado de entidades. En tales modelos, el estado actual es fácil de obtener leyendo una o más líneas o documentos. Vale la pena señalar que Event Sourcing y el modelo relacional no son mutuamente excluyentes. Los sistemas de abastecimiento de eventos a menudo incluyen ambos. La diferencia clave con Event Sourcing es que el almacén de entidades ya no se trata como datos sin procesar. Se puede reemplazar o reconstruir mediante el reprocesamiento del registro de eventos.
En sistemas de abastecimiento de eventos más complejos, los almacenes de estado derivados deben estar presentes para las solicitudes de lectura eficientes, ya que la recuperación del estado actual mediante el procesamiento de todo el registro de eventos a lo largo del tiempo puede detener el escalado. Tanto las bases de datos relacionales como las de documentos se pueden utilizar como un registro de eventos y como un repositorio de entidades derivadas, a través de las cuales puede obtener rápidamente el estado actual. De hecho, esta división de tareas es CQRS (Command Query Responsibility Segregation, división de responsabilidad en comandos y consultas). Todas las solicitudes se enrutan al almacén derivado para que pueda optimizarse independientemente de las operaciones de escritura.
Aparte de la parte técnica, hay otros puntos a los que merece la pena prestar atención.
Problemas potenciales de abastecimiento de eventos
A pesar de las ventajas de Event Sourcing, también tiene desventajas.
Los mayores desafíos suelen estar en la mentalidad de los desarrolladores. Los desarrolladores deben ir más allá de las aplicaciones CRUD convencionales y las tiendas de entidades. Los eventos deberían convertirse ahora en el concepto principal.
Con Event Sourcing, se dedica mucho esfuerzo a modelar eventos. Una vez que los eventos se escriben en el registro, deben considerarse sin cambios; de lo contrario, el historial y el estado pueden estar corruptos o dañados. El registro de eventos son los datos sin procesar, lo que significa que debe tener mucho cuidado para asegurarse de que contiene toda la información necesaria para obtener el estado completo del sistema en un momento determinado. También debe tenerse en cuenta que los eventos pueden ser reinterpretados a medida que el sistema (y el negocio que representa) cambia con el tiempo. Y no te olvides de los eventos erróneos y sospechosos con el correcto procesamiento de la validación de datos.
Para modelos de dominio simples, este cambio de pensamiento puede ser bastante fácil, pero para modelos de dominio más complejos puede ser un problema (especialmente con muchas dependencias y relaciones entre entidades). Puede resultar difícil integrarse con sistemas externos que no proporcionan datos en un momento determinado.
El abastecimiento de eventos puede funcionar bien en sistemas grandes porque el patrón de registro de eventos se escala de forma natural en forma horizontal. Por ejemplo, el registro de eventos de una entidad no tiene que residir físicamente con el registro de eventos de otra entidad. Sin embargo, esta facilidad de escalado conduce a problemas adicionales en forma de procesamiento asincrónico y, finalmente, datos consistentes. Los comandos para cambiar el estado pueden llegar a cualquier nodo, después de lo cual el sistema necesita determinar qué nodos son responsables de las entidades correspondientes y enviar el comando a estos nodos, luego procesar el comando y luego replicar los eventos generados a otros nodos donde se almacenan los registros de eventos. Y solo después de la finalización de este proceso, el nuevo evento pasa a estar disponible como parte del estado del sistema.Por lo tanto, Event Sourcing realmente requiere que el procesamiento de comandos esté separado de la solicitud de estado, es decir, CQRS.
Por lo tanto, los sistemas de suministro de eventos deben tener en cuenta el intervalo de tiempo entre la emisión de un comando y la recepción de una notificación sobre el registro de eventos exitoso. El estado del sistema que ven los usuarios en este momento puede ser "incorrecto". O mejor dicho, un poco anticuado. Para reducir la influencia de este factor, es necesario tenerlo en cuenta a la hora de diseñar la interfaz de usuario y en otros componentes. También es necesario manejar adecuadamente las situaciones en las que un comando falla, se cancela durante la ejecución o un evento se reemplaza por uno más nuevo cuando se actualizan los datos.
Otro problema surgirá cuando los eventos se acumulen con el tiempo y será necesario trabajar con ellos. Una cosa es simplemente escribirlos después del procesamiento, y otra es trabajar con todo el historial. Sin esta funcionalidad, el registro de eventos pierde completamente su valor. Esto es especialmente cierto para la recuperación ante desastres o al migrar almacenes derivados, cuando es posible que sea necesario volver a procesar todos los eventos para actualizar los datos. Para sistemas con una gran cantidad de eventos, el reprocesamiento de todo el registro puede exceder el tiempo de recuperación permitido. Las instantáneas periódicas del sistema pueden ayudar aquí para que pueda comenzar a recuperarse de un estado saludable posterior.
También es necesario considerar la estructura de los eventos. La estructura de los eventos puede cambiar con el tiempo. El conjunto de campos puede cambiar. Puede haber situaciones en las que la lógica empresarial actual deba procesar eventos antiguos. Y la presencia de un esquema de eventos expandible ayudará en el futuro, si es necesario, a distinguir los eventos nuevos de los antiguos. Las instantáneas periódicas también ayudan a aislar los cambios importantes en la estructura de los eventos.
conclusiones
Event Sourcing es un enfoque poderoso con beneficios. Uno de ellos es facilitar la expansión del sistema en el futuro. Dado que el registro de eventos almacena todos los eventos, se pueden utilizar en sistemas externos. Es bastante fácil de integrar agregando nuevos controladores de eventos.
Sin embargo, al igual que con cualquier decisión arquitectónica importante, debe tener cuidado para asegurarse de que funcione para su situación. Las restricciones relacionadas con la complejidad del dominio, los requisitos de consistencia y disponibilidad de los datos, así como el aumento en el volumen de datos almacenados y la escalabilidad a largo plazo, deben considerarse todos ellos (y esta no es una lista exhaustiva). Es igualmente importante prestar atención a los desarrolladores que desarrollarán y mantendrán dicho sistema durante todo su ciclo de vida.
Y finalmente, no olvide el principio más importante de la ingeniería de software: esfuércese por mantener todo lo más simple posible (el principio KISS).
