database - sourcing - estrategia de db mejor abastecimiento de eventos

event store

Question

Quiero configurar un pequeño evento sourcing lib. Leí algunos tutoriales en línea, todo entendido hasta ahora.

El único problema es que, en estos tutoriales diferentes, hay dos estrategias de base de datos diferentes, pero sin ningún comentario sobre por qué usan la que usan.

Por lo tanto, quiero pedir su opinión. Y lo más importante, ¿por qué prefieres la solución que elijas?

1. La solución es la estructura db en la que se crea una tabla para cada evento.

2. La solución es la estructura de base de datos en la que solo crea una tabla genérica y guarda los eventos como una cadena serializada en una columna.

En ambos casos, no estoy seguro de cómo manejan los cambios de eventos, tal vez crean uno completamente nuevo.

Saludos cordiales

Answer 1

La solución es la estructura db donde creas solo una tabla genérica y guardas los eventos como una cadena serializada en una columna

Este es, con mucho, el mejor enfoque, ya que la repetición de eventos es más simple. Ahora mis dos centavos en la fuente de eventos: es un gran patrón, pero debes tener cuidado porque no todo es tan simple como parece. En un sistema en el que estuve trabajando, guardamos la secuencia de eventos por agregado, pero aún teníamos un conjunto de tablas normalizadas, porque no podíamos aceptar eso para obtener el estado más reciente de un objeto, tendríamos que ejecutar todos los eventos. (Las instantáneas ayudan pero no son una solución perfecta). Así que sí, la fuente de eventos es un buen patrón, le brinda un control de versiones completo de sus entidades y un registro de auditoría completo, y debe usarse solo para eso, no como un reemplazo de un conjunto de tablas normalizadas, pero esto es solo mis dos. centavos

Answer 2

Aquí están las dos estrategias para acceder a los datos sobre un tema involucrado en este caso. 1) estado actual y 2) secuenciación de eventos. Con el estado actual procesamos los eventos, pero mantenemos solo el último estado del sujeto. Con la secuenciación de eventos mantenemos los eventos y reconstruimos el estado actual procesando los eventos cada vez que necesitamos el estado. La secuenciación de eventos es más confiable, ya que podemos rastrear todo lo que sucedió causando el estado actual, pero definitivamente no es eficiente. Es un sentido común mantener también los estados intermedios (instantáneas) no solo el último para evitar reprocesar todos los eventos todo el tiempo. Ahora tenemos confiabilidad y rendimiento.

En las monedas criptográficas están la secuenciación de eventos y las instantáneas locales: el nombre local se debe a que las cadenas de código se distribuyen y los datos se replican.

Answer 3

Construí mi propia biblioteca de fuentes de eventos y opté por la opción 2 y he aquí por qué.

• Usted consulta la secuencia de eventos por tipo de evento id id.
• Reproducir los eventos en orden sería una pena si todos están en diferentes tablas
• Haría un poco doloroso actualizar los eventos.

Hay un argumento para decir que puede almacenar eventos en un agregado, pero eso depende de los requisitos del proyecto.

Tengo algunas publicaciones sobre cómo se utilizan las secuencias de eventos que pueden resultarle útiles.

6 El código huele con tus eventos CQRS y cómo evitarlos

Raíz agregada: cómo crear una para CQRS y la fuente de eventos

Cómo actualizar los eventos de CQRS sin destruir su flujo de eventos

Espero que les resulte útil.

Answer 4

Creo que la mejor solución será ir con # 2 . E incluso puede guardar su estado actual junto con el evento relacionado al mismo tiempo si usa un db transaccional como mysql.

Realmente no me gusta y recomiendo la solución # 1 .

Si su preocupación por el # 1 es sobre la actualización / actualización de eventos; luego declara una nueva clase para cada nuevo cambio. No seas demasiado perezoso; o obsesionarse con la reutilización. Hágales saber a los suscriptores sobre los cambios; Dales la versión del evento.

Si sus inquietudes para el # 1 son sobre algo como consultar / interpretar eventos; luego, más tarde, puede enviar fácilmente sus eventos a un nosqldb o almacén de eventos en cualquier momento (desde la base de datos original)

También; el patrón que utilizo para la gestión de eventos es algo así:

public interface IUserCreated : IEventModel
{
}
public class UserCreatedV1 : IUserCreated
{
public string Email { get; set; }
public string Password { get; set; }
}
public class UserCreatedV2 : IUserCreated
{
// Fullname added to user creation. Wrt issue: OA-143
public string Email { get; set; }
public string Password { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
}
public class EventRecord<T> where T : IEventModel
{
public string SessionId { get; set; } // Can be set in emitter.
public string RequestId { get; set; } // Can be set in emitter.
public DateTime CreatedDate { get; set; } // Can be set in emitter.
public string EventName { get; set; } // Extract from class or interface name.
public string EventVersion { get; set; } // Extract from class name
public T EventModel { get; set; } // Can be set in emitter.
}
public interface IEventModel { }

Asi que; hacer que las versiones y actualizaciones de eventos sean explícitas; Tanto en el dominio como en el código base. Implementar el manejo de nuevos eventos en los suscriptores antes de implementar el origen de nuevos eventos. Y; si no es necesario, no permita el consumo directo de eventos de dominio de suscriptores externos; Poner una capa de integración o algo así.

Deseo que mis pensamientos te sean útiles.

Answer 5

Leí sobre un enfoque de abastecimiento de eventos que consiste en:

1. Teniendo dos tablas: agregado y evento;

2. base en sus casos de uso:

   a. crea y registra en la tabla agregada, genera una ID, versión = 0 y un tipo de evento y crea un evento en la tabla de eventos;

   segundo. recupere de la tabla agregada, los eventos por ID o tipo de evento, aplique los casos comerciales y luego actualice la tabla agregada (versión y tipo de evento) y luego cree un evento en la tabla de eventos.

Aunque este enfoque actualiza algunos campos en la tabla agregada, deja la tabla de eventos solo como anexo y mejora el rendimiento ya que tiene la última versión de un agregado en la tabla agregada.

Answer 6

Me gustaría ir con el número 2, y si realmente desea tener una forma eficiente de búsqueda a través del tipo de evento, simplemente agregaría un índice en esa columna.