Conceptos básicos de Event Sourcing

Introducción al aprovisionamiento por eventos

Al principio (0:00), Derek habla de la confusión en torno al aprovisionamiento de eventos y los conceptos básicos asociados. Define el aprovisionamiento de eventos no sólo como "capturar el estado actual", sino como almacenar eventos, es decir, capturar todos los cambios que se producen en el modelo de dominio en un registro de sólo apéndices.

De este modo, se mantiene un historial completo de los cambios de estado del sistema. En lugar de persistir sólo el estado final, se persisten los eventos que reflejan la lógica de negocio que se ha producido.

Eventos: Captura de hechos empresariales

En el minuto 0:33, Derek explica qué es realmente un evento. Un evento representa algo que ya ha ocurrido en el sistema: un hecho empresarial. Por ejemplo, un evento "ProductReceived" contendría la cantidad recibida y la fecha.

Derek subraya que cuando se almacenan eventos, deben nombrarse utilizando una convención de nomenclatura que refleje el tiempo pasado, como "Producto enviado" o "Inventario ajustado". En un esquema de eventos, puede haber campos como Id Guid público, Nombre cadena pública y marcas de tiempo.

Cada evento también debe tener un identificador único, crucial para un sistema de almacenamiento de sólo anexión en el que se anexan eventos a un flujo de eventos.

Event Streams: Organización de eventos

A las 2:02, Derek pasa a los flujos de eventos. Establece una comparación con una tabla de base de datos relacional, pero explica que, en el aprovisionamiento de eventos, todos los eventos relacionados con un objeto de dominio (como un artículo de inventario) pertenecen al mismo flujo de eventos.

Cada flujo de eventos está vinculado a una entidad específica, a menudo definida por un Id Guid público y un Nombre de cadena. Por ejemplo, un producto con SKU ABC123 tendría su propio flujo que contendría eventos persistentes como la recepción o el envío.

Derek sugiere que, a la hora de modelarlas, se piense en términos de raíces agregadas y objetos de dominio, tomando prestados conceptos de diseño orientado al dominio.

El modelado del ciclo de vida, ya sea de corta o larga duración, ayuda a optimizar el número y el tamaño de los flujos. Esto es crucial para mejorar el rendimiento en sistemas complejos.

Proyecciones y modelos de lectura

En el minuto 4:12, Derek presenta las proyecciones y el modelo de lectura. Dado que su sistema de origen de eventos captura eventos en lugar de solo el estado actual, debe reproducir eventos para responder a preguntas como "¿Cuál es la cantidad de inventario actual?"

Para construir modelos de lectura, se procesan eventos del flujo. Por ejemplo, utilizando private void Apply(Event e) o similar, se incrementa o disminuye el stock basándose en los manejadores de eventos para cada tipo de evento.

Derek ilustra cómo construir un modelo de lectura en una base de datos de documentos o en una base de datos relacional: quizá una proyección muestre simplemente la cantidad disponible y otra el historial de envíos.

Esto refleja la segregación de responsabilidad de consulta de comandos (CQRS): separar las operaciones de escritura (comandos) de las operaciones de lectura (consultas).

Proyecciones para modelos de escritura

En el minuto 6:48, Derek muestra cómo aplicar proyecciones también en el lado de la escritura. Esto es crucial para validar las acciones antes de permitir que se lleven a cabo.

En un gestor de comandos, antes de enviar productos, es necesario verificar que existe una cantidad suficiente. Derek utiliza un método como private void Apply(List events) para reconstruir el estado necesario.

Campos como public int Version ayudan a seguir la evolución del flujo, garantizando su coherencia.

Esta implementación práctica ayuda a hacer cumplir la lógica de negocio cuando se manejan nuevos eventos, asegurando que su sistema sólo actúe en transiciones de estado válidas.

Suscripciones: Reaccionando a nuevos eventos

A las 8:01, Derek habla de las suscripciones. Las suscripciones permiten a los consumidores de eventos escuchar nuevos eventos y reaccionar.

Por ejemplo, un proyector puede suscribirse a un flujo de eventos y actualizar un modelo de lectura cuando vea un evento "Producto enviado". Alternativamente, un editor puede escuchar eventos y publicarlos en sistemas externos como RabbitMQ o Kafka, integrándose con otros servicios.

Derek describe las suscripciones no sólo para la actualización de modelos internos, sino también para la distribución de datos a través de sistemas de eventos separados, preservando la coherencia eventual.

Esto demuestra otra de las grandes ventajas de la arquitectura basada en eventos: sus servicios siguen siendo coherentes en última instancia, pero escalables de forma independiente.

Recapitulación de conceptos básicos

En el minuto 9:21, Derek resume los conceptos básicos:

• Los eventos capturan hechos.

• Los flujos de eventos organizan los eventos por entidad.

• Las proyecciones convierten los flujos en modelos de lectura consultables o modelos de escritura procesables.

• Las suscripciones permiten que los servicios reaccionen y se actualicen en consecuencia.

Destaca que se persisten los eventos en un registro de sólo apéndice, se mantiene una pista de auditoría y se reproducen los eventos cuando es necesario.

Imágenes y optimización

A las 9:39, Derek aborda el tema de las instantáneas. Aunque a menudo se habla de ellas junto con el aprovisionamiento de eventos, aclara que las instantáneas son una optimización del rendimiento más que un requisito básico.

Las instantáneas reducen la sobrecarga de reproducir todos los eventos guardando un estado parcial periódicamente, pero el historial completo sigue existiendo a través del registro de sólo apéndices.

Distinción clave: Event Sourcing vs Event Driven Architecture

A las 10:00, Derek advierte sobre un error muy común: ¡la arquitectura basada en eventos y la arquitectura basada en eventos son diferentes! Herramientas como Kafka ayudan con la distribución de datos, pero el verdadero aprovisionamiento de eventos se centra en el registro de eventos de dominio como una pista de auditoría inmutable.

Comprender la distinción es crucial a la hora de integrar el aprovisionamiento de eventos en sus complejos sistemas.

Conclusión

Siguiendo el vídeo de Derek Comartin, está claro que el aprovisionamiento de eventos consiste en registrar cada cambio como un evento, no sólo el estado final. Al almacenar eventos en un sistema de almacenamiento de sólo apéndices, se construye un esquema de eventos rico que proporciona una pista de auditoría, flexibilidad para la consulta de eventos y un soporte robusto para la segregación de responsabilidad de consulta de comandos.

Tanto si estás trabajando con eventos de C# en .NET Core como en cualquier otra plataforma, la explicación estructurada de Derek de los conceptos básicos, los controladores de eventos, los conjuntos privados, los conjuntos protegidos y la aplicación de eventos como private void Apply() en tus modelos es increíblemente valiosa.

Si estás trabajando en la construcción de un modelo de dominio resistente, la mejora de su sistema de almacenamiento, o la creación de patrones complejos con varios beneficios como la consistencia eventual, el estudio del enfoque de Derek es una necesidad. Echa un vistazo a su canal de YouTube para ver más vídeos interesantes.