A fonte de eventos ( fonte de eventos, registro de eventos, geração de eventos) é um poderoso padrão de arquitetura em que todas as alterações feitas no estado do aplicativo são salvas na ordem em que ocorreram. Esses registros servem como fonte para obter o estado atual e como trilha de auditoria do que aconteceu no aplicativo durante sua vida útil. O fornecimento de eventos facilita a alteração e leitura descentralizada de dados. Essa arquitetura é bem dimensionada e adequada para sistemas que já estão trabalhando com tratamento de eventos ou desejam migrar para essa arquitetura.
O que é Event Sourcing
Os especialistas em domínio geralmente descrevem seus sistemas como uma coleção de entidades , que são contêineres para armazenar estados e eventos que refletem mudanças nas entidades como resultado do processamento de dados de entrada em vários processos de negócios. Os eventos geralmente são acionados por comandos vindos de usuários, processos em segundo plano ou integrações com sistemas externos.
Essencialmente, a fonte de eventos concentra-se em eventos relacionados a mudanças no sistema.
Muitos padrões arquitetônicos vêem as entidades como um conceito primário. Esses modelos descrevem como salvá-los, como acessá-los e como modificá-los. Dentro desse estilo arquitetônico, os eventos costumam ser "laterais": eles são as consequências da mudança de entidades.
Normalmente, essas arquiteturas são baseadas em um armazenamento de entidade, como um banco de dados relacional ou armazenamento de documentos. Embora os eventos possam estar presentes em tal arquitetura, eles, em sua essência, não são um conceito primário e podem ser separados das entidades às quais estão associados, bem como escondidos atrás de camadas de lógica de negócios.
O Event Sourcing inverte essa abordagem, focando na implementação de eventos: como eles são persistentes e como podem ser usados para obter o estado de uma entidade. Neste caso, o banco de dados conterá um log sequencial de todos os eventos ocorridos durante a existência do sistema.
Abaixo está uma comparação do Armazenamento de eventos com o Armazenamento de entidades (descrito em mais detalhes posteriormente):
O fornecimento de eventos, usando eventos como o principal conceito de arquitetura, também é um paradigma de modelagem de domínio que reflete melhor a visão do sistema do cliente. Projetar sistemas com ênfase em eventos e registros de eventos oferece os seguintes benefícios:
- , « » .
- (command/query responsibility), .
- , , , .
Event Sourcing
Vejamos um exemplo simples com uma conta bancária. Teremos uma entidade que representa uma conta bancária. Para simplificar, criaremos apenas uma conta sem identificá-la usando o número da conta ou de qualquer outra forma. A conta manterá o saldo atual de fundos.
Dois comandos (comando) estarão disponíveis para a conta : depositar dinheiro (depositar) e retirar dinheiro (retirar). Os comandos indicarão o valor a ser depositado ou sacado. Também definiremos uma regra de negócios que verifica se um comando de saque só pode ser processado se o valor solicitado for igual ou inferior ao saldo da conta corrente.
Com esta abordagem, dois eventos podem ser distinguidos (evento)- “Conta creditada” e “Conta debitada”. Esses eventos contêm informações sobre o valor que foi depositado ou retirado. Isso poderia ser simplificado para um evento com uma soma positiva ou negativa, mas neste exemplo iremos dividi-los.
O diagrama abaixo mostra o modelo de dados.
Observe que os eventos são “pretérito”. Eles indicam o que aconteceu no sistema no momento em que foram gravados e são salvos apenas se o comando foi processado com sucesso. Com essa abordagem, deve-se ter cuidado para não confundir comandos com eventos. Especialmente se eles se espelharem.
A sequência de comandos pode ser semelhante a esta:
1. depósito {quantia: 100} - depósito 100
2. retirar {quantia: 80} - retirar 80
3. retirar {quantia: 50} - retirar 50
A implementação mais simples do Event Sourcing requer um log de eventos , que é simplesmente uma sequência de eventos. Ao processar os comandos acima, você obtém esse log.
O terceiro comando não pode ser executado porque o valor solicitado excede o saldo disponível.
Para obter o saldo atual, o sistema deve processar ou "gerar" eventos na ordem de sua ocorrência. Para nosso exemplo, pode ser assim:
- conta bancária {saldo atual: 0} (estado inicial)
conta bancária {saldo atual: 0} (estado inicial) - bank account { current balance: 100 } (processed: Account Credited, +100)
{ : 100 } (: , +100) - bank account { current balance: 20 } (processed: Account Debited, -80)
{ : 20 } (: , -80)
O saldo atual é calculado através do processamento de todos os eventos até o momento atual. Como cada evento possui um carimbo de data / hora implícito, é possível calcular o estado da conta a qualquer momento, processando todos os eventos pelo período de tempo necessário.
Este é um exemplo completo (embora trivial) de Event Sourcing. Em um sistema real, este exemplo provavelmente precisará ser estendido.
Pode ser necessário salvar a sequência de comandos para ser capaz de identificar como o evento ocorreu, bem como criar um log de eventos de erro separado no qual registrar os comandos que não foram concluídos, para posterior tratamento de erros e manutenção de um histórico completo de sucesso e equipes malsucedidas.
Com o tempo, conforme o número de comandos aumenta, pode ser necessário manter o saldo da conta corrente de modo que, quando um comando de retirada for recebido, não seja necessário processar a lista completa de eventos para determinar se o comando pode ser executado (ou seja, se a conta tem fundos suficientes). Este é um exemplo de armazenamento derivado e é essencialmente igual a um armazenamento de entidade.
Abaixo está como o armazenamento de entidade ficará para nosso exemplo depois de processar todos os comandos.
Obviamente, em comparação com um Event Store completo, este é um exemplo muito primitivo. E esta é uma das razões pelas quais muitos desenvolvedores usam apenas o armazenamento de entidade. Nesse caso, o saldo da conta corrente fica disponível imediatamente e não há necessidade de processar todos os eventos históricos.
No entanto, o Event Sourcing não exclui armazenamentos de entidades. Freqüentemente, as lojas de entidades também estão presentes em projetos de Event Sourcing.
Fim da primeira parte.
