O que não sou muito claro é por que você reidrataria seus agregados da própria loja de eventos.
Porque os "eventos" são o livro de registro.
Se projetar alterações nos bancos de dados "ler" é tão fácil, por que nem sempre projetar alterações em um banco de dados "gravar" cujo esquema corresponde perfeitamente ao seu modelo de domínio? Este seria efetivamente um banco de dados de instantâneos.
Sim; às vezes é uma otimização de desempenho útil usar uma cópia em cache do estado agregado, em vez de regenerar esse estado do zero toda vez. Lembre-se: a primeira regra de otimização de desempenho é "Não". Ele adiciona complexidade extra à solução, e você prefere evitar isso até ter uma motivação comercial atraente.
Se for esse o caso, o Armazenamento de Eventos é útil apenas ao reconstruir seu banco de dados "gravação" como resultado de alterações de esquema? Ou estou perdendo algo maior?
Está faltando algo maior.
O primeiro ponto é que, se você está considerando uma solução de origem de evento, é porque espera que haja valor em preservar o histórico do que aconteceu, ou seja, que você deseja fazer alterações não destrutivas .
É por isso que estamos escrevendo para a loja do evento.
Em particular, isso significa que todas as alterações precisam ser gravadas no armazenamento de eventos.
Os escritores concorrentes podem potencialmente destruir as gravações um do outro ou levar o sistema a um estado não intencional, se não estiverem cientes das edições um do outro. Portanto, a abordagem usual quando você precisa de consistência é direcionar suas gravações para uma posição específica no diário (análoga a uma PUT condicional em uma API HTTP). Uma gravação com falha informa ao escritor que seu entendimento atual do diário está fora de sincronia e que eles devem se recuperar.
Retornar a uma boa posição conhecida e reproduzir quaisquer eventos adicionais, pois esse ponto é uma estratégia de recuperação comum. Essa boa posição conhecida pode ser uma cópia do que está no cache local ou uma representação no seu armazenamento de instantâneos.
No caminho feliz, você pode manter um instantâneo do agregado na memória; você só precisa acessar um armazenamento externo quando não houver uma cópia local disponível.
Além disso, você não precisa ser completamente informado, se tiver acesso ao livro de registro.
Portanto, a abordagem usual ( se estiver usando um repositório de instantâneos) é mantê-lo de forma assíncrona . Dessa forma, se você precisar se recuperar, poderá fazê-lo sem recarregar e reproduzir o histórico inteiro do agregado.
Há muitos casos em que essa complexidade não é interessante, porque agregados refinados com vida útil no escopo geralmente não coletam eventos suficientes para que os benefícios excedam os custos de manutenção de um cache de captura instantânea.
Mas quando é a ferramenta certa para o problema, carregar uma representação obsoleta do agregado no modelo de gravação e atualizá-lo com eventos adicionais é uma coisa perfeitamente razoável a se fazer.