Evento de abastecimiento y persistencia

11

Estoy leyendo sobre el abastecimiento de eventos y tengo una pregunta sobre la persistencia.

Todavía puedo tener un DB con todas las entidades, ¿verdad? ¿O deberían repetirse los eventos cada vez que se inicia la aplicación para obtener la última versión de cada entidad en la memoria? ¿Parece un desperdicio en sistemas más grandes (como en una gran cantidad de datos)?

El punto con el abastecimiento de eventos es que puedo reproducir los eventos para llenar un almacén de datos si es necesario. (o analizar los datos)

event-sourcing

— jgauffin
fuente

9

Con Event Sourcing, la pregunta principal es "cuál es su libro de registro".

Si su libro de registro es su flujo de eventos, entonces no tendrá problemas. Si su libro de registro es su "modelo de entidad", los problemas comenzarán a suceder por todas partes. Parte de esto es que puede decir "si perdiera mi modelo de entidad, podría reconstruirlo a partir de mi secuencia de eventos". Si tiene una opinión positiva sobre esta pregunta, su Registro de eventos es su libro de registro.

También es importante recordar que la mayoría de las personas que usan fuentes de eventos usan un modelo de lectura. Este modelo se utiliza para consultar datos. Sin embargo, es más probable que esto se parezca a un modelo 1nf que a un modelo de entidad 3nf. Solo reproducen eventos para recuperar los estados de los agregados para determinar si se deben permitir las escrituras.

— Greg Young
fuente

Hola Greg, soy nuevo en el abastecimiento de eventos, pero realmente quiero dominar esto, ¿podrías sugerir algunos recursos para ejemplos prácticos y explicaciones? He visto y leído mucho sobre CQRS, ES, pero cuando quiero comenzar un prototipo utilizándolo, realmente no puedo entender qué dónde y cuándo :) Espero que me puedan sugerir algo (estoy del lado de Java). Gracias por tu tiempo.

— vach

8

Se beneficiará al máximo del abastecimiento de eventos cuando decida cambiar también la arquitectura de su sistema. Ir hacia una arquitectura de estilo CQRS combinada con DDD traerá los verdaderos beneficios de una fuente de eventos, al menos en mi opinión.

Crear una tienda de eventos que se comporte bien en sistemas grandes no es una tarea fácil. Reproducción de todos los datos puede ser costoso, depende mucho de la cantidad de datos que necesita reproducirse. Pero existen técnicas que pueden ayudarlo con esto, una de ellas es el concepto de una instantánea. La repetición se realiza solo desde cierto punto en adelante. Las ventajas que una tienda de eventos aporta a su sistema son invaluables. Teniendo todo lo que sucedió en su sistema reproducible, todos los datos en cada momento son una gran cosa. Piense en el análisis, en la reproducción de errores, en las estadísticas.

Hay muchas tiendas de eventos geniales, la última fue lanzada ayer Event Store y parece una muy buena.

La base de datos tradicional se puede mantener para la parte de consulta de su sistema para construir DTO con los datos solicitados. Esta base de datos se puede organizar y optimizar teniendo en cuenta las necesidades de consulta de su aplicación y clientes.

Escribí un artículo detallado sobre cuáles son los beneficios y cómo se ve realmente una arquitectura CQRS combinada con el abastecimiento de eventos. Puede consultar CQRS, Eventos de dominio y revisión DDD .

— Vadim
fuente

1

Sé todo sobre CQRS y DDD. Entiendo los beneficios del abastecimiento de eventos. Las instantáneas son una excelente manera de acelerar el proceso. Sin embargo, eso no es parte de la pregunta. Pero la pregunta era más bien dónde se almacenarían todos los modelos / entidades una vez cargados. ¿En memoria (requeriría MUCHA memoria en sistemas más grandes) o en un DB? ¿Cuál es la mejor práctica?

— jgauffin

1

Al recrear un agregado para realizar un comando dado, los eventos se reproducirían y el agregado se mantendría en la memoria, realizar la acción, generar los eventos y luego almacenar los eventos en el almacén de eventos. Pero sí, el agregado con sus objetos y entidades de valor se mantendría en la memoria. No es necesario mantenerlos en otra base de datos. Eso normalmente sería un corto período de tiempo hasta que el comando se complete de todos modos. Si tiene comandos que abarcan múltiples agregados que son un poco diferentes, también podría indicar algunos problemas de diseño con sus contextos acotados.

— Vadim

1

Todavía puedo tener un DB con todas las entidades, ¿verdad? ¿O deberían repetirse los eventos cada vez que se inicia la aplicación para obtener la última versión de cada entidad en la memoria?

La respuesta depende de los requisitos de su aplicación. Lo he visto hecho en ambos sentidos.

Un paquete de software extremadamente exitoso para pequeñas empresas de contabilidad lee su registro CQRS cada vez que se inicia. La cantidad bruta de datos era relativamente pequeña, por lo que el tiempo de inicio fue inferior a un minuto incluso en computadoras más lentas. Han estado haciendo CQRS durante más de una década antes de que la práctica se hiciera popular. Sabían que estaban haciendo algo bueno cuando se dieron cuenta de que pueden actualizar sus datos de clientes una y otra vez sin tener problemas que ven con sus sistemas más grandes.

En sistemas con grandes volúmenes de datos y / o sistemas que dependen de la funcionalidad RDBMS para implementar el lado de consulta, tiene una base de datos para la "vista actual" de los datos de origen de eventos (incluso puede tener múltiples vistas de este tipo). La ventaja de este enfoque es que le permite construir el lado de la consulta utilizando las tecnologías familiares.

— dasblinkenlight
fuente

¿Qué paquete de contabilidad hace esto?

— magnus

@ user1420752 Axys .

— dasblinkenlight