Origem e persistência de eventos

Estou lendo sobre a fonte de eventos e tenho uma pergunta sobre persistência.

Ainda posso ter um banco de dados com todas as entidades, certo? Ou os eventos devem ser repetidos toda vez que o aplicativo é iniciado para obter a versão mais recente de cada entidade na memória? Parece um desperdício em sistemas maiores (como em grande quantidade de dados)?

O ponto com a fonte de eventos é que eu posso reproduzir os eventos para preencher um armazenamento de dados, se necessário? (ou analise os dados)

Com o Event Sourcing, a questão principal é "qual é o seu livro de registro".

Se o seu livro de registro for o seu fluxo de eventos, você não terá problemas. Se o seu livro de registro for o seu "modelo de entidade", os problemas começarão a acontecer em todo o lugar. Parte disso é que você pode dizer "se eu perdi meu modelo de entidade, poderia reconstruí-lo a partir do meu fluxo de eventos". Se você está positivo nessa questão, seu Log de eventos é o seu livro de registro.

Também é importante lembrar que a maioria das pessoas que usa a fonte de eventos usa um modelo de leitura. Este modelo é usado para consultar dados. É mais provável que isso pareça um modelo de 1nf do que um modelo de entidade de 3nf. Eles apenas reproduzem eventos para recuperar os estados dos agregados para determinar se as gravações devem ser permitidas.

Você se beneficiará ao máximo da fonte de eventos quando decidir alterar também a arquitetura do sistema. Ir para uma arquitetura de estilo CQRS combinada com DDD trará os verdadeiros benefícios de uma fonte de eventos, pelo menos na minha opinião.

Construir um armazenamento de eventos que se comporte bem em sistemas grandes não é uma tarefa fácil. A reprodução de todos os dados pode ser cara, depende muito da quantidade de dados que precisa ser reproduzida. Mas existem técnicas que podem ajudá-lo com isso, sendo uma delas o conceito de um instantâneo. A repetição é feita apenas a partir de um certo ponto em diante. As vantagens que um armazenamento de eventos traz para o seu sistema são inestimáveis. Tendo tudo o que aconteceu no seu sistema reproduzível, todos os dados em todos os momentos são ótimos. Pense na análise, na reprodução de bugs, nas estatísticas.

Existem muitas ótimas lojas de eventos, a última foi lançada ontem Event Store e parece realmente boa.

O banco de dados tradicional pode ser mantido para a parte de consulta do seu sistema criar DTOs com os dados solicitados. Esse banco de dados pode ser organizado e otimizado, considerando as necessidades de consulta do seu aplicativo e clientes.

Escrevi um artigo detalhado sobre quais são os benefícios e como é realmente uma arquitetura CQRS combinada com a fonte de eventos. Você pode conferir CQRS, eventos de domínio e revisão de DDD .

Ainda posso ter um banco de dados com todas as entidades, certo? Ou os eventos devem ser repetidos toda vez que o aplicativo é iniciado para obter a versão mais recente de cada entidade na memória?

A resposta depende dos requisitos do seu aplicativo. Eu já vi isso nos dois sentidos.

Um pacote de software extremamente bem-sucedido para pequenas empresas de contabilidade lê seu registro CQRS toda vez que é iniciado. A quantidade bruta de dados era relativamente pequena; portanto, o tempo de inicialização era inferior a um minuto, mesmo em computadores mais lentos. Eles praticam o CQRS há mais de uma década antes de a prática se tornar popular. Eles sabiam que estavam conseguindo algo bom quando perceberam que podem atualizar os dados de seus clientes repetidamente, sem encontrar problemas que vêem em seus sistemas maiores.

Em sistemas com volumes maiores de dados e / ou sistemas que dependem da funcionalidade RDBMS para implementar o lado da consulta, você possui um banco de dados para a "visualização atual" dos dados originados por eventos (você pode até ter várias visualizações). A vantagem dessa abordagem é que ela permite criar o lado da consulta usando as tecnologias familiares.