Persistiendo y consultando múltiples estados en diferentes momentos en arquitectura de Event Sourcing.
Estoy tratando de entender cómo abordar este problema en un escenario con eventos. Tengo un objeto de dominio que utiliza la metodología de eventos. Quiero hacer diferentes tipos de agregaciones y consultas en el objeto, pero me gustaría poder consultar diferentes puntos en el tiempo en la “vida útil” del objeto.
Quizás un ejemplo lo aclare: tengo un objeto que representa un contrato. Tengo múltiples etapas para el contrato: la última versión, la versión previa a la firma, la primera versión que recibe nuestro cliente, etc.
Los usuarios quisieran poder consultar este objeto ‘Contrato’ en diferentes puntos en el tiempo (tanto consultas de búsqueda como de agregación). Los datos se guardan y consultan en múltiples ubicaciones (como es común en las proyecciones de lectura de Event Sourcing).
Me pregunto cuál sería la forma estándar de almacenar múltiples ‘estados’ de dicho objeto de una manera que me permita consultarlos. ¿Es mejor opción duplicar los datos con otra proyección de lectura? Las actualizaciones en los almacenes de datos tampoco son muy posibles, ya que algunos de los modelos de lectura proyectados no se almacenan en una base de datos que permita actualizaciones.
¿Alguna vez te has encontrado con un escenario así en un sistema de eventos? ¿Cómo abordaste este problema?
davy.ai
En un escenario basado en eventos, un enfoque para manejar múltiples estados de un objeto de dominio es crear diferentes proyecciones de lectura para cada estado. Cada proyección correspondría a un punto diferente en el tiempo de vida del objeto y almacenaría la información necesaria para realizar las consultas y agregaciones requeridas para ese estado.
Por ejemplo, en el caso de un objeto Contrato, se podrían crear proyecciones de lectura para la última versión del contrato, la versión pre-firmada, la primera versión entregada al cliente, etc. Cada proyección almacenaría la información necesaria para ese estado particular del contrato, como los términos del contrato, las firmas, la fecha de entrega, etc.
Estas proyecciones se actualizarían a medida que se agregan nuevos eventos al flujo de eventos, lo que modificaría el estado actual del objeto. Cuando se necesita ejecutar una consulta para un punto específico en el tiempo, se leería la proyección correspondiente y se ejecutaría la consulta en ella.
Es importante destacar que este enfoque puede llevar a la duplicación de datos en las proyecciones. Sin embargo, esta duplicación es un compromiso necesario para garantizar que las proyecciones estén optimizadas para las consultas y agregaciones necesarias para cada estado específico del objeto.
En resumen, para manejar múltiples estados de un objeto de dominio en un escenario basado en eventos, se deben crear diferentes proyecciones de lectura para cada estado y almacenar la información necesaria para cada estado en la proyección correspondiente. Este enfoque permite consultas y agregaciones optimizadas para cada estado específico y asegura que las proyecciones siempre estén actualizadas.