Apresentação sobre event sourcing, utilizando um sistema desenvolvido em Kotlin, Spring Boot, Axon e React no front end. Utilizei o domínio bancário como exemplo para implementação do event sourcing.

1. Event Sourcing

2. Autor
WELLINGTON G. MACEDO
/wellington3110
/in/wgmacedo
wellingtongustavomacedo@gmail.com

3. Código usando na apresentação

4. Agenda
● O que é evento;
● Event Sourcing;
○ Aggregator
○ Projections;
○ Reactors;
● Prós;
● Contras;
● Ferramentas;
● Quem está usando;

5. O que ambas operações possuem em comum?

6. Ambas são eventos!

7. Exemplos de eventos:
● Bater o ponto;
● Puxar uma tarefa do JIRA;
● Pagar a passagem do ônibus;
● Ligar para um amigo;
● Entre outros milhares de exemplos...

8. Event Sourcing

9. O Event Sourcing é um pattern que descreve que todas as
mudanças no estado da aplicação sejam armazenadas como
uma sequência de eventos.

10. Os eventos são guardados no que chamamos de
Event Store.

11. Eventos são imutáveis. O Event Store só permite inserção e
leitura.

12. Vamos reproduzir os eventos em um sistema real.

13. Aggregate
Aggregate agrega os eventos de um determinado
subdomínio da sua aplicação.

14. Qual foi o fluxo utilizado para gerar esses eventos no
sistema?

15. Receive Command
Transform command
into event
Save the event
Is command
ok?
Response with
error
Start
Response with
OK
Event
Store
Commands:
● CreateAccountCommand
● FundsDepositCommand
● FundsWithdrawCommand
Events::
● CreatedAccountEvent
● FundsDepositedEvent
● FundsWithdrawnEvent
error

16. Foi requerido para o time de engenharia uma feature para
mostrar o balanço da conta, como é possível desenvolver
isso se não é guardado o estado da aplicação?

18. Projection

19. Uma projection representa o estado atual de algum modelo.

20. Event
Store
DepositFundsCommand
WithdrawFundsCommand
Balance
Projector SQL
Database
Storing
FundsDepositedEvent
Storing
FundsWithdrawnEvent
Tailing
FundsDepositedEvent
and
FundsWithdrawnEvent
Save
Projection .

21. Agora foi solicitado ao time de engenharia exibir o maior
depósito já feito pelo cliente, como podemos desenvolver
isso?
Pergunta

22. Event
Store
DepositFundsCommand
WithdrawFundsCommand
Balance
Projector
SQL
Database
Storing
FundsDepositedEvent
Storing
FundsWithdrawnEvent
Tailing
FundsDepositedEvent
and
FundsWithdrawnEvent
Save
Projection .
BiggestDeposit
Projector
Tailing
FundsDepositedEvent
Save
Projection .

23. Event
Store
DepositFundsCommand
WithdrawFundsCommand
Balance
Projector SQL
Database
Storing
FundsDepositedEvent
Storing
FundsWithdrawnEvent
Tailing
FundsDepositedEvent
and
FundsWithdrawnEvent
Save
Projection .
BiggestDeposit
Projector
Tailing
FundsDepositedEvent
Save
Projection .
Redis

24. Event
Store
DepositFundsCommand
WithdrawFundsCommand
Balance
Projector SQL
Database
Storing
FundsDepositedEvent
Storing
FundsWithdrawnEvent
Tailing
FundsDepositedEvent
and
FundsWithdrawnEvent
Save
Projection .
BiggestDeposit
Projector
Tailing
FundsDepositedEvent
Save
Projection .
PDF

25. Event
Store
DepositFundsCommand
WithdrawFundsCommand
AccountSummary
Projector SQL
Database
Storing
FundsDepositedEvent
Storing
FundsWithdrawnEvent
Tailing
FundsDepositedEvent
and
FundsWithdrawnEvent
Save
Projection .
Replay events

26. Projections
● Projectors deveriam ser desacoplados um dos outros e
não deveriam compartilhar nenhum estado;
● Projectors e projections são desacoplados;
● Projectors são assincronos;
● O projector pode ter um bookmark indicando onde está
processando atualmente.

27. Por fim o time do produto pediu que quando:
- Balanço do cliente for menor que R$ 100;
- Cliente tentar sacar dinheiro;
Então:
- Deve enviar um e-mail avisando o cliente;

28. Reactor

29. Reactors reagem a eventos, por exemplo, desencadeando
algum comportamento externo ou emitindo novos eventos.

30. Event
Store
WithdrawFundsCommand
BalanceControlReactor
Storing
FundWithdrawnEvent
Send email to the client
Tailing
FundWithdrawnEvent

31. Reactor
● Reactors deveriam ser desacoplados um dos outros e
não deveriam compartilhar nenhum estado;
● Reactors podem ser stateless ou stateful;
● Não deveriam ter acesso a projections ao realizar sua
lógica;
● Reactors são assincronos;
● Reactors deveriam fazer apenas uma coisa bem.

32. PRÓS

33. Tratar o core do seu negócio com o máximo respeito.

34. Diminui o "impedance mismatch".

35. Iteração e reinterpretação.

36. Encoraja boas práticas.

37. Evita pontos comum de dor.

38. Contras

39. Consistência Eventual

40. Mapeamento de eventos

41. Complexidade

42. Opacidade

43. Flexibilidade de operação

44. Ferramentas - em nível de código

45. Ferramentas - em nível de infraestrutura

46. Quem está usando

47. Referências
● http://udidahan.com/2009/12/09/clarified-cqrs/
● https://medium.com/@hugo.oliveira.rocha/what-they-dont-tell-you-about-event-sourcing-6afc2
3c69e9a
● https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf
● https://martinfowler.com/eaaDev/EventSourcing.html
● https://microservices.io/patterns/data/event-sourcing.html
● https://ookami86.github.io/event-sourcing-in-practice/#further-reading-1.md
● https://github.com/luontola/cqrs-hotel
● https://www.youtube.com/watch?v=iGt0DBOWDTs
● https://dev.to/barryosull/event-sourcing-what-it-is-and-why-its-awesome
● https://medium.com/serialized-io/event-sourcing-explained-part-2-some-things-you-should-kno
w-about-a929940c1d5c

48. Dúvidas?