Conceitos básicos de Event Sourcing

Introdução ao Event Sourcing

No início (0:00), Derek discute a confusão em torno do Event Sourcing e os conceitos principais associados. Ele define Event Sourcing não apenas como "capturar o estado atual", mas como armazenar eventos — registrando cada alteração que ocorre no seu modelo de domínio em um log somente de acréscimo.

Dessa forma, você mantém um histórico completo das alterações de estado do seu sistema. Em vez de persistir apenas o estado final, você persiste eventos que refletem a lógica de negócios que ocorreu.

Eventos: Capturando Dados Empresariais

Aos 0:33, Derek explica o que é realmente um evento. Um evento representa algo que já ocorreu dentro do sistema — um fato comercial. Por exemplo, um evento "ProdutoRecebido" conteria a quantidade recebida e a data.

Derek enfatiza que, ao armazenar eventos, eles devem ser nomeados usando uma convenção de nomenclatura que reflita o tempo passado, como "Produto Enviado" ou "Estoque Ajustado". Em um esquema de eventos, você pode ter campos como ID Guid público, nome (string pública) e registros de data e hora.

Cada evento também deve ter um identificador único, crucial para um sistema de armazenamento somente de acréscimo, onde você está acrescentando eventos a um fluxo de eventos.

Fluxos de eventos: Organizando eventos

Às 2h02, Derek faz a transição para os fluxos de eventos. Ele faz uma comparação com uma tabela de banco de dados relacional, mas explica que, no conceito de Event Sourcing, todos os eventos relacionados a um objeto de domínio (como um item de estoque) pertencem ao mesmo fluxo de eventos.

Cada fluxo de eventos está vinculado a uma entidade específica — geralmente definida por um ID Guid público e um nome em formato de string. Por exemplo, um produto com SKU ABC123 teria seu próprio fluxo contendo eventos persistentes, como recebimento ou envio.

Derek sugere que, ao modelar esses elementos, você pense em termos de raízes agregadas e objetos de domínio, inspirando-se em conceitos de design orientado a domínio.

Modelar o ciclo de vida — seja ele de curta ou longa duração — ajuda a otimizar o número e o tamanho dos fluxos. Isso é crucial para melhorar o desempenho em sistemas complexos.

Projeções e Modelos de Leitura

Às 4:12, Derek apresenta as projeções e o modelo de leitura. Como seu sistema baseado em eventos captura eventos em vez de apenas o estado atual, você precisa reproduzir os eventos para responder a perguntas como "Qual é a quantidade atual em estoque?".

Para construir modelos de leitura, você processa eventos do fluxo. Por exemplo, usando private void Apply(Event e) ou similar, você incrementa ou decrementa o estoque com base nos manipuladores de eventos para cada tipo de evento.

Derek ilustra como construir um modelo de leitura em um banco de dados de documentos ou em um banco de dados relacional — talvez uma projeção simplesmente mostre a quantidade em estoque, outra mostre o histórico de remessas.

Isso reflete a segregação de responsabilidades de comando e consulta (CQRS): a separação das operações de escrita (comandos) das operações de leitura (consultas).

Projeções para modelos de escrita

Às 6h48, Derek mostra como aplicar projeções também no lado da escrita. Isso é crucial para validar as ações antes que elas sejam permitidas.

Em um manipulador de comandos, antes de enviar os produtos, é necessário verificar se existe quantidade suficiente. Derek usa um método como private void Apply(List eventos) para reconstruir o estado necessário.

Campos como public int Version ajudam a rastrear a evolução do fluxo, garantindo consistência eventual.

Essa implementação prática ajuda a reforçar a lógica de negócios ao lidar com novos eventos, garantindo que seu sistema atue apenas em transições de estado válidas.

Assinaturas: Reagindo a Novos Eventos

Às 8h01, Derek fala sobre assinaturas. As assinaturas permitem que os consumidores de eventos ouçam novos eventos e reajam a eles.

Por exemplo, um projetor pode se inscrever em um fluxo de eventos e atualizar um modelo de leitura quando detectar um evento de "Produto Enviado". Alternativamente, um editor pode ficar à escuta de eventos e publicá-los em sistemas externos como o RabbitMQ ou o Kafka, integrando-se a outros serviços.

Derek descreve as assinaturas não apenas para atualizar modelos internos, mas também para distribuição de dados entre sistemas de eventos separados, preservando a consistência eventual.

Isso demonstra outra grande vantagem da arquitetura orientada a eventos: seus serviços permanecem eventualmente consistentes, mas escaláveis ​​de forma independente.

Revisão dos Conceitos Essenciais

Às 9h21, Derek resume os conceitos principais:

• Os eventos registram fatos.

• Os fluxos de eventos organizam eventos por entidade.

• As projeções transformam fluxos em modelos de leitura consultáveis ​​ou modelos de gravação acionáveis.

• As assinaturas permitem que os serviços reajam e se atualizem de acordo.

Ele destaca que você deve persistir os eventos em um log somente para anexação, manter um registro de auditoria e reproduzir os eventos quando necessário.

Capturas de tela e otimização

Às 9h39, Derek aborda o tema da captura de instantâneos. Embora frequentemente discutido em conjunto com o event sourcing, ele esclarece que os snapshots são uma otimização de desempenho, e não um requisito fundamental.

Os snapshots reduzem a sobrecarga de reproduzir todos os eventos, salvando um estado parcial periodicamente, mas o histórico completo ainda existe por meio do log de acréscimo único.

Principal distinção: Event Sourcing vs. Arquitetura Orientada a Eventos

Às 10h, Derek alerta sobre um equívoco comum: Event Sourcing e Arquitetura Orientada a Eventos são diferentes! Ferramentas como o Kafka auxiliam na distribuição de dados, mas o verdadeiro event sourcing se concentra no registro de eventos do domínio como uma trilha de auditoria imutável.

Compreender essa distinção é crucial ao integrar o event sourcing em seus sistemas complexos.

Conclusão

Após assistir ao vídeo de Derek Comartin, fica claro que o event sourcing consiste em registrar cada mudança como um evento, e não apenas o estado final. Ao armazenar eventos em um sistema de armazenamento somente para acréscimo, você cria um esquema de eventos rico que fornece um registro de auditoria, flexibilidade para consultar eventos e suporte robusto para segregação de responsabilidade de consulta de comando.

Quer você esteja lidando com o recurso de Event Sourcing em C# no .NET Core ou em qualquer outra plataforma, a explicação estruturada de Derek sobre os conceitos básicos, manipuladores de eventos, conjuntos privados, conjuntos protegidos e a aplicação de eventos como private void Apply() em seus modelos é incrivelmente valiosa.

Se você está trabalhando na construção de um modelo de domínio resiliente, aprimorando seu sistema de armazenamento ou criando padrões complexos com diversas vantagens, como consistência eventual, estudar a abordagem de Derek é essencial. Não deixe de conferir o canal dele no YouTube para mais vídeos esclarecedores.