EASIER IMPOSSIBLE | Architect with EVENT SOURCING | Pros, Cons and REAL SCENARIOS
ฝัง
- เผยแพร่เมื่อ 30 ก.ย. 2024
- Knowing and understanding real scenarios, pros and cons to apply a pattern is fundamental, and that's exactly what we bring in this TOP content, with extremely didactic explanations, real cases all explained on the ArcH Blackboard.
Event Sourcing is an extremely well-known and relevant design pattern, it can solve various issues related to GDPR, data auditing and various other processes that require history storage procedures and undo capabilities.
Introduced in 2005 by Martin Fowler, the Event Sourcing pattern has been simplifying complex challenges related to Software Architecture and Solutions.
Understand in this content the most IMPORTANT points about Event Sourcing, including the use of Kafka, event stream and data modeling.
Also watch our content on CQRS, it has absolutely everything to do with Event Sourcing:
• CQRS: Hangouts EXCLUSI...
------
EASIER IMPOSSIBLE | Architect with EVENT SOURCING | Pros, Cons and REAL SCENARIOS
----
Become a VIP at ArcH, follow me on my new Telegram channel:
t.me/pisanidaarch
---
Cross technological content, can be applied to java, rust, .net, c#, php, nodejs, javascript, go lang etc
ArcH is a digital content producer that monthly helps thousands of professionals to become FERA in SYSTEM ARCHITECTURE, here are some of the topics we cover: architectural approaches, design standards, architecture and technology standards with efficiency, agility and quality, all to contribute to the professional development of the community of Solution Architects\Software and Systems in Brazil.
Learn more about ArcH:
▶ archoffice.tech
---
CONTACT:
▶ Whats: (11) 9.9696-8533
▶ Email: pisani@archoffice.tech
Caramba, super explicação, 23 minutos muito bem investidos, parabéns Pisani 👏👏👏
Muito obrigado pela participação de sempre 🤙
Estranho o Kafka como banco de eventos nesse desenho, ele parece ficar melhor como o componente de Streaming, no final do dia ele seria um "banco de dados" dos eventos
kafka para armazenar eventos???? Imagina você tem uma partição com 1 M , imagina seu id de payment está na partição 50 k, vai ter que ler 955 k , nada performatico!!!!
Estou implementando uma arquitetura de microsserviços em spring java para um sistema bancário (trabalho de faculdade) e um dos serviços é justamente o serviço de Conta que foi pedido para usar CQRS. Eu não sabia como modelar as tabelas-entidade, vou seguir essa sua proposta, eu não havia pensado em implementar uma tabela exclusiva para o Saldo, soa como uma ideia muito boa, só fiquei na dúvida se não deveria haver uma relação de um para um entre as tabelas Statement e Balance, eu vou criar um vinculo entre elas para os extratos, contudo a duvida principal de como guardar o histórico de saldos foi resolvida, eu estava colocando o balance como atributo da Conta, obviamente isto estava me causando muitos problemas, e a lição mais importante é aprofundar a modelagem de banco de dados, a falta de conhecimento de BD ferra demais com nossa vida de desenvolvedor. Muito obrigado pelo video, mais uma ajuda no meio de tantos problemas que já tive até agora.
Senti falta de alguns pontos:
- Fala sobre projections , possibilitar reports diferenciado para cada viewer.
- Fala sobre snapshots, ajuda no processo de reply ou load dos eventos.
- Necessariamente o event store não precisa está dentro do broker, temos libs que nos fornecem isso como por exemplo: Marten e EventStoreDB
- Um ponto que discordo é que evento é a causa da mudança e sim a mudança propriamente dita ou seja o fato acontecido no passado mediante uma ação, por isso todo comando gera um evento e dar muito match com CQRS.
- Falar sobre a estruturação dos dados que segue um modelo tabular ou documento separado por basicamente 5 campos: ID, Event Type, TimeStamp, Data e Version.
- Falar sobre a importância da ordenação da stream.
- Falar porque o event sourcing da muito matching com saga coreografada e não orquestrada.
Enfim rsrs, é isso.
Caceta!
Excelente explicação 👏🏻👏🏻👏🏻😈
Olá Vanessa, muito obrigado pelo feedback
Qual a real vantagem do enabled no balance sendo que somente o mais recente vai ser o válido? Não seria melhor não ter esse campo e sempre buscar pelo balanço mais recente? No statement até faria sentido pelo que você explicou, sendo que você talvez precise manualmente "desativar" um statement, mais no caso do balance eu não consigo ver uma razão lógica.
Meu caro, desculpa, mas eu discordo de diversos pontos no vídeo.
Para começar que entendo que o microservice deve possuir sua própria base de dados, logo, ele deve ser responsável exclusivamente pelo seu domínio e por consequência, seus dados. Um MS pode ser arquitetado com ES ou não. Mas se ele compartilhar a base de dados e/ou depender de outro serviço para funcionar, não é um microservice.
Escala: essa solução aí não escala, afinal você tem um Gateway de apis orquestrando processamento e todos dependem da mesma fonte de eventos.
Envio de dados no payload: eu discordo veementemente da prática de disparar dados em eventos. Afinal, o produtor do evento nunca conhece o consumidor do dado, o que pode levar a um sério problema de vazamento de informações. O evento deveria apenas trafegar chaves primária que permitam aos consumidores consultar mais informações através de apis, onde de fato é possível aplicar políticas de segurança.
Enfim, tenho mais pontos e adoraria debater sobre eles e os pontos de vista.
Abraços
Fala Lucas, tudo 100%? Embora seja um conteúdo relativamente antigo, eu acredito que ele ainda faça bastante sentido.
Mas sobre os pontos elencados, existem, padrões consolidados, opiniões e soluções baseadas na combinação de tudo isso com resultados positivos no mundo real.
Muito do que eu divido vem la do comecinho da Micro-Componentização mais de 15 anos atrás (me senti vovô agora 😅) nos grupos de MDA com o Richardson, Pattric, Viscond, Fowler e confesso de me lembrar de que sempre haviam muitas discussões neste imenso grupo inclusive em torno deste tipo de solução.
Evidentemente, respeito sua opinião e sou grato pela sua participação 👊
No caso do Event Sourcing precisamos sim enviar o payload.
Quando adotamos o Event Sourcing precisamos que o payload contenha as informacoes de alteracoes do dominio utilizando apenas IDs voce esta colaborando para uma arquitetura que construi uma dependencia forte entre os microsservicos realizando essa consulta http/rest entre os microsservicos.
Outro ponto que colabora para a utilizaçao dos Payload é o seguinte cenario: Imagina que voce esta construindo uma base de leitura otimizada em grafos por exemplo consultando um recurso lento para leitura nesse cenario voce teria de onerar essa base lenta de leitura toda vez que um evento for lançado.
Grande Pisani, gostei da explicação, as vezes usamos certos conceitos e não nos damos conta e quando isso acontece, não é raro usarmos de forma errada. Parabéns pelo vídeo.
Faz vídeo com código.
Fala Ricardo, muito obrigado pelo feedback, nós vamos voltar a ter, o problema maior tem sido o tempo para produção, este vídeo de cabo a rabo levou cerca de 3.5 horas para ser feito, com um código legal e coerente vai para 6 ou mais facilmente. Assim que reduzir um pouco nossas outras demandas vamos para alguns hands on 👊🏻
Muito bem explicado!
Fala Henrique muito obrigado pelo feedback, tmj 👊🏻👊🏻👊🏻
Muito bom!!! Tem me ajudado bastante com o seu conteúdo!
Conteúdo muito bom, obrigado por compartilhar.
Opa, sou eu quem agradeço, muito obrigado pelo feedback 👊🏻
Explicacao sensasional! Parabens
Muito obrigado 👊🏻
Top. Gostei muito do vídeo.
Opa show demais, muito obrigado pelo feedback 👊🏻
Sucesso!
Parabéns! Pela primeira vez assisti não só a uma explicação objetiva sobre o pattern mas também sua aplicação em cases reais.
Fala Paulo, que legal que você gostou, muito obrigado pelo feedback.