Event Sourcing, sagas, barramento e consistência eventual

Question

Event Sourcing, sagas, barramento e consistência eventual

#1 resposta do (5 votos)

5

Atualmente, estou aprendendo sobre o Sourcing de Eventos por meio do livro Microsoft .NET - Arquitetando Aplicativos para a Empresa . O sourcing de eventos é, em minhas próprias palavras, um padrão arquitetônico de armazenar "eventos" em vez de "entidades atuais". As entidades atuais podem ser criadas passando por cima dos eventos pertencentes a ela.

O problema de desempenho da criação de entidades atuais pode ser atenuado criando um armazenamento extra onde periodicamente as entidades atuais são "instantâneas" (criadas a partir do instantâneo anterior e os eventos que aconteceram depois dele).

No livro, a arquitetura pertencente à Origem do evento é configurada da seguinte forma:

Aqui, todos os eventos (relacionados a um jogo de pólo aquático) são armazenados em um armazenamento NoSQL RavenDB. Também vemos um ônibus para acompanhar os eventos e uma saga que pertence a grupos de eventos.

Tenho algumas perguntas sobre o Event Sourcing (decidi perguntar a todos de uma vez, pois todas as perguntas estão relacionadas à descrição no livro):

Eu estou querendo saber de que maneira esses eventos seriam armazenados. Eu posso imaginar que os dados em eventos podem mudar ao longo do tempo (propriedades extras, novos nomes de eventos) e que os eventos precisam ser facilmente relacionados uns aos outros e a si mesmo. Como a estrutura atual do banco de dados e o código de acesso a dados procuram facilitar a mudança e a recuperação de dados?
O que é uma saga? Por que isso é chamado de saga? Eles persistiram e, em caso afirmativo, como?
Como funciona um ônibus? Quais são as vantagens de apenas gravar eventos diretamente em um armazenamento de eventos?
Na arquitetura acima, em que comandos e consultas são separados (CQRS) e os comandos são implementados usando o Event Sourcing enquanto as consultas são lidas no instantâneo, o que acontece quando os dados precisam ser exibidos durante o início de um comando? (Por exemplo, mostrando dados da conta bancária enquanto um usuário deseja fazer um depósito, com base nesses dados.) Como, na prática, garantimos que os dados exibidos estejam atualizados?

architecture architectural-patterns cqrs eventual-consistency event-sourcing

por Erwin Rooijakkers 29.08.2015 / 17:38

fonte

1 resposta

Tags architecture architectural-patterns cqrs eventual-consistency event-sourcing

Mapeando modelos de domínio para ViewModel Incluindo uma biblioteca para usar uma classe de função / utilitário

score 5 · Accepted Answer

Armazenamento de eventos

O armazenamento de eventos dependerá do seu aplicativo, mas será muito mais fácil se você usar um armazenamento flexível para seus eventos (para um banco de dados NoSQL, JSON ou XML). O modo como você lida com as atualizações dependerá de vários fatores que você precisa levar em conta, como requisitos de disponibilidade e prazos para atualizações, quantidade de eventos, etc.

Atualize seus eventos quando o aplicativo for atualizado: como parte da implantação de um novo aplicativo, atualize todos os eventos anteriores para o novo esquema
Versão dos seus eventos: tenha um ID de versão no seu evento. Quando um evento é lido no banco de dados, algum pedaço de código sabe como 'atualizar' eventos antigos para a estrutura atual. Como a primeira opção, mas basicamente 'on demand'
Jogue fora seus eventos antigos: quando o aplicativo for atualizado, crie um instantâneo de todas as entidades e jogue fora (ou arquive) os eventos antigos.
Nunca jogue fora eventos antigos: basicamente mantenha 'PurchaseOrder' para sempre. Quando você precisar de outro campo, use um novo evento como "PurchaseOrderWithCouponCode".

Saga

Uma saga é basicamente um evento de longa duração cortado em pedaços. Isto pode ser devido a diferentes razões: pode ser porque você quer ter uma ação que resulte em vários eventos tratados em paralelo para evitar o bloqueio com uma transação, porque você precisa coordenar vários sistemas externos ou porque precisa coordenar com eventos que cruzam um contexto limitado. Você precisa persisti-los por esse motivo: uma saga pode ser iniciada, lançar alguns eventos e, em algum ponto não-determinístico, pode ser necessário retomar o lançamento de mais eventos. Udi Dahan tem uma boa introdução sobre isso.

Barramentos de mensagens

Há muito que se pode dizer sobre os ônibus. Eles abstraem uma grande parte do armazenamento de eventos para você e podem lidar com cenários mais complicados, por exemplo, quando você tem vários aplicativos que precisam trabalhar com o armazenamento de eventos. Para pequenos aplicativos, você pode escrever diretamente no armazenamento de eventos (e o código que faria isso poderia ser considerado um barramento ...)

Dados atualizados

Resposta curta: você não faz. A terceirização de eventos funciona de várias maneiras porque você é "eventualmente consistente". Neste exemplo, você pode simplesmente exibir uma mensagem para os usuários que pode levar até dez minutos para que os depósitos sejam exibidos ...