Fazer com que um sistema lance eventos de notificação para toda modificação no estado de uma entidade abre espaço para algumas soluções interessantes.
Podemos, por exemplo, usar os eventos de notificação para, além de permitir implementação desacoplada de consistência eventual entre aplicações, contar a “história” de uma entidade, através de uma técnica conhecida como Event Sourcing.
A ideia central da técnica é reconhecer que o estado de uma entidade é “explicado” pela ocorrência de uma sequência clara de eventos, em uma ordem determinada.
Com posse do histórico de eventos de notificação de alteração de estado, podemos restituir qualquer um dos “estados históricos” de uma entidade, bastando, para isso, que realizar um replay do seu histórico de eventos até o ponto apropriado.
Em termos simples, matendo o histórico de eventos armazenado, podemos “recuperar” o estado de uma entidade, em qualquer momento. Podemos também saber quando mudanças ocorreram, quem fez essas mudanças e qual foi a intenção de negócio. Poderoso, porém complexo!
Sistemas que usam event sourcing costumam manter, além da base de eventos, uma outra base com materializações do estado da entidade em algum momento (geralmente o atual).
Essa materialização é útil por ser extermamente fácil de pesquisar. Podemos pensar essas materializações como “fotografias” do estado da entidade em algum momento. Talvez por isso, convencionou-se utililizar a designação snapshot.
A base de dados utilizada para armazenar eventos geralmente é nosql (o NuBank, por exemplo, utiliza Datomic para registrar transações). A base para os snapshots pode ser quaquer uma, inclusive relacionais. Aliás, Greg Young, que formalizou o conceito de Event Sourcing, criou um banco de dados para armazenar eventos chamado EventStore.
Há diversas implementações de event sourcing em sistemas de mercado. Ou seja, existem diversos sistemas que mantém um histórico de eventos para justificar o estado de suas entidade.
Em um banco, poderíamos assumir que o “estado” do nosso saldo atual é explicado por uma série de eventos registrados em nosso extrato. No Github, o estado de nosso código fonte é explicado por uma série de commits.
De qualquer forma, event sourcing está longe de ser tópico ou prática comum. Há uma diversidade gigantesca de complicações para uma implementação correta e precisa existir uma justificativa muito forte para que você o adote.
Já implementou um sistema usando event sourcing? Compartilhe suas impressões.
Primeiramente parabéns pelo post e pelo conteúdo, que vem postando(realmente dotnet além do crud).
Event sourcing ou o uso de mensageria tem que justificar muito em um projeto. A complexidade aumenta muito até para depurar, com qualquer que seja a tecnologia escolhida (Rabbitmq, Kafka, Akka). Grandes poderes, Grandes responsabilidades.
Parabéns pelo artigo!!!
Já tive experiência com event-sourcing, mas não de um sistema e sim parte dele.
Nesse caso era referente a um cadastro de taxa de prestação de serviço, esta informação era enviada via integração por outro sistema. Então, todas as mudanças da entidade era armazenada numa estrutura NoSQL. Assim era possível ver quando a forma de cobrança era alterada e o motivo.
Elemar, me tire uma duvida por favor. Digamos que eu tenha um sistema onde parte dele é CRUD simples, onde vou ter configurações de alguns atributos para serem usados em processamento futuro. E a outra parte do sistema é referente a este processamento, onde com base nas configurações feitas nos CRUDs irei tomar decisões, essas decisões poderiam ser tratadas como eventos. Seria errado para o CRUD eu usar uma abordagem mais simples (sem eventos) e para a parte do processamento ai sim eu usaria eventos, handlers, etc?
E outra dúvida é com relação ao armazenamento de estado, é obrigatório ou boa prática ter armazenado o estado atual do meu item?