Skip to main content

Event Sourcing e Event Driven Architecture | Arquitetura

  • Event Sourcing e Event Driven Architecture | Arquitetura
info

Artigo: https://medium.com/codigorefinado/event-driven-x-event-sourcing-1b9756d4df15 Vídeo no Youtube: https://www.youtube.com/watch?v=J7ze_DJOpB4

Diferenças:

  • Event Sourcing se concentra em como você armazena e mantém o estado de um sistema usando uma sequência de eventos, o que é especialmente útil quando se precisa de um histórico completo e uma fonte de verdade para o estado de uma entidade.

  • Event-Driven é uma abordagem arquitetônica que se concentra em como os sistemas se comunicam entre si e respondem a eventos em tempo real, promovendo o desacoplamento e a escalabilidade.

Event Driven Architecture​

Vídeo Gago: https://www.youtube.com/watch?v=J7ze_DJOpB4

warning

Se o assunto de Governança não é discutido na empresa, provavelmente a arquitetura de eventos não se encaixa muito bem

danger

Explicação

Event-Driven não é sobre “quebrar o sistema em 100 microserviços”. É sobre criar fluxos assíncronos e desacoplados, mesmo em uma arquitetura monolítica. Imagine um monolito de ERP que precisa processar milhares de notas fiscais ao final do dia (batch job). O fluxo clássico seria:

  • Uma chamada gigante a um serviço;
  • O sistema trava recursos até terminar;

Se der erro, começa de novo.

Agora, e se o processamento fosse orientado a eventos?

  • Cada nota fiscal gera um evento NotaCriada.
  • Um worker interno (ou externo) consome esses eventos em lote ou em tempo real.
  • O core do monolito publica eventos para uma fila (RabbitMQ, Kafka, até Redis).
  • O processamento pesado acontece de forma assíncrona, sem bloquear o fluxo principal. E teu sistema vai ter:
  • Escalabilidade mesmo sem microserviços.
  • Processamento em lote controlado por consumo de fila.
  • Facilidade em isolar falhas (erros não travam o sistema inteiro).
  • preparação natural para uma futura migração para microsserviços (se fizer sentido, claro).
  • Trata de criações de eventos de negócio que propaga pelo meu ecossistema. Desacopla o código de imperativo para reativo. Eu notifico alguém que algo aconteceu e alguém faz algo com isso.

Ex: Serviço 1, 2 e 3

  • Modo acoplado: Serviço 1 para enviar algo para o serviço 2 precisa saber o protocolo do serviço 2 (HTTP, etc ...)(acoplado ao serviço 2)

Event Notification | Command, Event | Acoplamento​

  • Os comandos tem um acoplamento absurda com os parâmetros que o serviço espera
  • Os eventos mão tem acoplamento, apenas está preocupado em dizer que alguma coisa aconteceu alt text

Event-Carried State Transfer​

  • Envia todos os dados necessários dentro do evento

Event Sourcing​

  • Event Sourcing é um padrão onde as alterações no estado da aplicação são armazenadas como uma sequência de eventos. Em vez de armazenar apenas o estado atual dos dados em um domínio, o Event Sourcing armazena um log de todas as alterações (eventos) que ocorreram ao longo do tempo. Isso permite que o aplicativo reconstrua estados passados e fornece uma trilha de auditoria de alterações. O Event Sourcing é benéfico em cenários que exigem transações comerciais complexas, auditabilidade e a capacidade de reverter ou reproduzir eventos

CQRS​

  • Segmentar escrita e leitura
    • Obtém benefícios como: Performance