Event Sourcing en Azure - parte 1: plan de arquitectura

David Guida
Computación en la nube
July 6, 2021

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



David Guida

Passionate, hard-working, and innovative software engineer with a strong desire for continuous learning and improving.
Over 15 years of experience in different domains, including Healthcare, Finance, and large-scale e-Commerce.

Microsoft MVP for Developer Technologies, confident on back-end and front-end tech stacks including .NET, NodeJs, PHP, Angular, React, as well as extensive experience on SQL, MongoDB, Azure, and GCP.

Everything is "just a tool". The secret is to know which one best suits your needs.

https://www.davidguida.net/

Related Posts

Boletin informativo SpainClouds.com

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form