Event Sourcing: Armazenando Estado como Sequência de Eventos

Event Sourcing é um padrão arquitetural onde, em vez de armazenar apenas o estado atual dos dados, você armazena uma sequência de eventos que levaram a esse estado.

Cada mudança no sistema é capturada como um evento imutável, permitindo reconstruir o estado a qualquer momento reproduzindo os eventos.

Conceitos Fundamentais

Evento: Representa algo que aconteceu no passado. Sempre nomeado em tempo passado (past tense). Exemplos: PedidoCriado, ItemAdicionado, PagamentoProcessado.

Event Store: Banco de dados append-only que armazena todos os eventos em ordem cronológica. Pode ser implementado com EventStoreDB, PostgreSQL ou até Kafka.

Projeções: Views materializadas do estado atual, reconstruídas a partir dos eventos. Otimizadas para consultas específicas.

Comparação: CRUD vs Event Sourcing

No modelo tradicional CRUD, você executa UPDATE e perde o histórico. Impossível auditar ou fazer rollback preciso.

Com Event Sourcing, você tem histórico completo preservado, auditoria natural e pode reconstruir estado em qualquer ponto no tempo.

Exemplo Prático: Conta Bancária

Imagine uma conta com eventos: ContaAberta (R$ 1000), DepositoRealizado (R$ 500), SaqueRealizado (R$ 100).

Para saber o saldo atual, você reproduz os eventos: 1000 + 500 - 100 = R$ 1400. Simples e auditável.

Vantagens

Auditoria Completa: Todo histórico é mantido naturalmente. Perfeito para compliance e regulamentações financeiras ou de saúde.

Debug Temporal: Pode reproduzir bugs reconstruindo o estado no momento exato do erro. Invaluável para diagnóstico.

Event Replay: Permite criar novas projeções a partir de eventos históricos sem migração de dados.

Análise de Negócio: Dados ricos para análise de comportamento, tendências e machine learning.

Desafios

Complexidade: Curva de aprendizado íngreme. Requer mudança de mentalidade da equipe.

Consultas: Queries complexas exigem projeções bem planejadas. Não é trivial fazer JOIN de eventos.

Evolução de Schema: Eventos são imutáveis. Mudanças requerem versionamento cuidadoso ou upcasting.

Snapshots: Para agregados com muitos eventos, snapshots periódicos são necessários para performance.

Quando Usar

Use quando auditoria é crítica (financeiro, saúde), histórico completo é valioso, análise temporal é importante, ou em sistemas distribuídos com eventual consistency.

Evite quando sistema é CRUD simples, consultas complexas em tempo real são necessárias, time não tem experiência, ou não há necessidade de histórico.

Implementação

A estrutura básica envolve um Event Store com métodos append (escrever) e getEvents (ler). O agregado aplica eventos sequencialmente para reconstruir estado.

Use snapshots a cada N eventos para otimizar. Combine com CQRS para separar escrita (eventos) de leitura (projeções).

Ferramentas

EventStoreDB é um database especializado. Apache Kafka funciona bem para event streaming. Axon Framework para Java/Spring, NEventStore para .NET, e até PostgreSQL pode ser usado como event store.

Conclusão

Event Sourcing é poderoso mas não é bala de prata. Use quando o histórico completo e auditoria são essenciais para o negócio.

Combine com CQRS para máxima efetividade. Comece pequeno, com agregados específicos, antes de aplicar no sistema inteiro.