Leia a primeira parte.

Recursos de implementação de Event Sourcing
Do ponto de vista técnico, o Event Sourcing requer apenas uma implementação de eventos de registro e leitura do registro.
No caso mais simples, um arquivo pode ser usado como o armazenamento de eventos, no qual um evento separado é registrado em cada linha, ou vários arquivos, quando cada evento é salvo em um arquivo separado. Mas, como regra, em grandes sistemas que exigem paralelismo e escalabilidade, são usados métodos de armazenamento mais confiáveis.
O log de eventos é um padrão muito comum usado em conjunto com o Message broker (middleware orientado a mensagens) e sistemas de processamento de fluxo de eventos. Um agente de mensagens, usado como um log de eventos, pode armazenar todo o histórico de mensagens, se necessário.
Os modelos relacionais e documentais geralmente se concentram na modelagem de entidades. Em tais modelos, o estado atual é fácil de obter lendo uma ou mais linhas ou documentos. É importante notar que o Event Sourcing e o modelo relacional não são mutuamente exclusivos. Os sistemas de fornecimento de eventos geralmente incluem ambos. A principal diferença com o Event Sourcing é que o armazenamento de entidade não é mais tratado como dados brutos. Ele pode ser substituído ou reconstruído por meio do reprocessamento do log de eventos.
Em sistemas de Event Sourcing mais complexos, os armazenamentos de estados derivados devem estar presentes para solicitações de leitura eficientes, uma vez que a obtenção do estado atual por meio do processamento de todo o log de eventos ao longo do tempo pode parar de escalar. Os bancos de dados relacionais e de documentos podem ser usados como um log de eventos e como um repositório para entidades derivadas, por meio do qual você pode obter rapidamente o estado atual. Na verdade, essa separação de interesses é CQRS (Command Query Responsibility Segregation). Todas as solicitações são roteadas para o armazenamento derivado para que ele possa ser otimizado independentemente das operações de gravação.
Além da parte técnica, há outros pontos que merecem atenção.
Possíveis problemas de terceirização de eventos
Apesar das vantagens do Event Sourcing, ele também apresenta desvantagens.
Os maiores desafios geralmente estão na mentalidade dos desenvolvedores. Os desenvolvedores devem ir além dos aplicativos CRUD convencionais e armazenamentos de entidades. Os eventos agora devem se tornar o conceito principal.
Com o Event Sourcing, muito esforço é gasto na modelagem de eventos. Depois que os eventos são gravados no log, eles devem ser considerados inalterados, caso contrário, o histórico e o estado podem ser corrompidos ou corrompidos. O log de eventos são os dados brutos, o que significa que você precisa ter muito cuidado para garantir que contenha todas as informações necessárias para obter o estado completo do sistema em um determinado momento. Deve-se ter em mente que os eventos podem ser reinterpretados à medida que o sistema (e o negócio que ele representa) muda ao longo do tempo. E não se esqueça de eventos errôneos e suspeitos com correto processamento de validação de dados.
Para modelos de domínio simples, essa mudança de pensamento pode ser muito fácil, mas para modelos de domínio mais complexos pode ser um problema (especialmente com muitas dependências e relacionamentos entre entidades). Pode ser difícil integrar com sistemas externos que não fornecem dados em um determinado momento.
A fonte de eventos pode funcionar bem em grandes sistemas porque o padrão de log de eventos é naturalmente escalonado horizontalmente. Por exemplo, o log de eventos de uma entidade não precisa residir fisicamente com o log de eventos de outra entidade. No entanto, essa facilidade de dimensionamento leva a problemas adicionais na forma de processamento assíncrono e dados eventualmente consistentes. Os comandos para alterar o estado podem chegar a qualquer nó, após o qual o sistema precisa determinar quais nós são responsáveis pelas entidades correspondentes e enviar o comando para esses nós, em seguida, processar o comando e replicar os eventos gerados para outros nós onde os logs de eventos são armazenados. E somente após a conclusão desse processo, o novo evento torna-se disponível como parte do estado do sistema.Assim, o Event Sourcing realmente requer que o processamento do comando seja separado da solicitação de status, ou seja, CQRS.
Portanto, os sistemas de Event Sourcing precisam levar em consideração o intervalo de tempo entre a emissão de um comando e o recebimento de uma notificação sobre o registro de eventos bem-sucedido. O estado do sistema que os usuários veem neste momento pode estar “errado”. Ou melhor, um pouco desatualizado. Para reduzir a influência desse fator, é necessário levá-lo em consideração ao projetar a interface do usuário e em outros componentes. Também é necessário tratar adequadamente as situações em que um comando falha, é cancelado durante a execução ou um evento é substituído por um mais recente quando os dados são atualizados.
Outro problema surgirá quando os eventos se acumularem ao longo do tempo e será necessário trabalhar com eles. Uma coisa é apenas anotá-los após o processamento, outra é trabalhar com toda a história. Sem essa funcionalidade, o log de eventos perde completamente seu valor. Isso é especialmente verdadeiro para recuperação de desastres ou ao migrar armazenamentos derivados, quando todos os eventos podem precisar ser reprocessados para atualizar os dados. Para sistemas com um grande número de eventos, o reprocessamento de todo o log pode exceder o tempo de recuperação permitido. Instantâneos periódicos do sistema podem ajudar aqui para que você possa iniciar a recuperação de um estado íntegro mais tarde.
Também é necessário considerar a estrutura dos eventos. A estrutura dos eventos pode mudar com o tempo. O conjunto de campos pode mudar. Pode haver situações em que eventos antigos precisem ser processados pela lógica de negócios atual. E a presença de um esquema de eventos expansível ajudará no futuro, se necessário, a distinguir novos eventos dos antigos. Instantâneos periódicos também ajudam a isolar mudanças importantes na estrutura dos eventos.
conclusões
O Event Sourcing é uma abordagem poderosa com benefícios. Um deles é facilitar a expansão do sistema no futuro. Como o registro de eventos armazena todos os eventos, eles podem ser usados em sistemas externos. É bastante fácil de integrar adicionando novos manipuladores de eventos.
No entanto, como acontece com qualquer decisão arquitetônica importante, você precisa ter cuidado para se certificar de que funciona para sua situação. Restrições relacionadas à complexidade do domínio, aos requisitos de consistência e disponibilidade dos dados, bem como ao aumento do volume de dados armazenados e escalabilidade no longo prazo, todas elas devem ser consideradas (e esta não é uma lista exaustiva). É igualmente importante prestar atenção aos desenvolvedores que desenvolverão e manterão tal sistema durante todo o seu ciclo de vida.
E, finalmente, não se esqueça do princípio mais importante da engenharia de software - esforce-se para manter tudo o mais simples possível (o princípio KISS).
