Event Sourcing en Azure - parte 1: plan de arquitectura
¡Hola todos! Con esta publicación, comenzaremos una nueva serie sobre abastecimiento de eventos en Azure. Hablaremos un poco sobre el patrón, la arquitectura general y los bloques de construcción individuales. Luego, en las próximas publicaciones, profundizaremos más y veremos cada una en detalle.
Si eres un lector habitual de este blog, es posible que sepas que ya escribí sobre Event Sourcing en el pasado . Es un patrón complejo, probablemente uno de los más complejos de corregir. Disfruto de los desafíos que ofrece y cómo hace que se evalúen en conjunto una gran cantidad de otros patrones (¿ CQRS alguien?).
Y como cualquier otro patrón, no hay soluciones mágicas . La arquitectura y la implementación cambiarán según las necesidades del dominio.
Pero podemos presentar “rápidamente” la idea general y luego apartarnos de ella en función de nuestras necesidades (o debería decir las necesidades comerciales ).
¡Empecemos por la arquitectura!
A la izquierda tenemos los comandos (o lado de escritura ), comencemos con eso. Se accederá a los comandos que expone nuestro sistema a través de REST Endpoints a través de una API web. También podríamos usar Azure Functions con un disparador HTTP, pero hablaremos más sobre esto en otra publicación de la serie.
Cualquiera que sea la forma que elijamos para comunicarnos con el mundo exterior, los comandos primero pasarán por una fase de validación contra las reglas comerciales. Esto suele suceder al rehidratar la raíz agregada de eventos pasados y realizar una serie de operaciones en ella.
Luego, si todo está bien, los comandos se traducen a Eventos de dominio y se conservan en nuestra Tienda de eventos. Usaremos CosmosDB para esto.
Luego, tenemos que publicar eventos de integración para informar a otras partes del sistema que sucedió "algo". Esto será manejado por Azure Service Bus Topic . Usaremos Topics en lugar de colas simples porque es posible que tengamos diferentes tipos de consumidores interesados en un tipo de evento en particular. Y, por supuesto, queremos implementar, operar y escalar a esos consumidores de forma independiente.
Uno de estos consumidores será una App de Azure Functions con un rol muy importante: materializar nuestros modelos de consulta . Al consultar datos, no podemos, por supuesto, rehidratar los agregados cada vez. Sí, obtendríamos datos consistentes cada vez, pero sería excesivo, incluso si usáramos instantáneas .
Entonces, nos suscribimos a los Topics y cada vez que recibimos un evento, actualizamos una versión específica de la consulta de los datos y la almacenamos en otro almacenamiento. Seguiremos usando CosmosDB en nuestro ejemplo.
Las vistas materializadas tienen la gran ventaja de ser exactamente lo que necesita nuestra aplicación de llamadas, incluidos todos los datos agregados posibles. Además, en caso de que cambien nuestros requisitos, siempre podemos agregar nuevas vistas o actualizar las existentes. Siempre que tengamos el flujo de eventos original, podemos eliminar todas las vistas y reconstruirlas desde cero con un bajo costo.
Eso es todo por hoy. La próxima vez veremos cómo podemos manejar la persistencia de eventos. ¡Ciao!
Traducido por: Juan Pablo Vidalit
