loading...

re: Event Sourcing Parte 4: Domain Events VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Olá, obrigado e parabéns pelo artigo :). Se me permite alguns comentários, talvez eles nem façam sentido por você ter comentado sobre esses pontos ...
 

Fala, Tiago. Tudo bom?

Vou te responder por tópico:
1) Sobre eventos do modelo e de domínio.

Sim! Falo sobre isso em artigos anteriores, mas sua dúvida não é menos pertinente por causa disso!

Uso o termo "modelo" porque corresponde a um modelo de domínio (martinfowler.com/eaaCatalog/domain...), que pode ser uma entidade ou um agregado caso apliquemos ao DDD. A ideia é ser abrangente na definição para não me prender ao DDD, já que ele não é um requisito para o uso do padrão ES, mas outros textos na internet dão a entender que seja.
Sendo assim, quando me refiro evento do modelo, trato de um evento restrito à auditoria deste modelo, e que não dispara um processo de negócio.

Já um evento de domínio é seu oposto: não diz respeito à auditoria do estado da entidade, mas é de interesse de outros modelos do domínio – entenda o termo "relevância" como "interesse", acho que a separação fica mais clara.

Talvez haja uma confusão entre a definição de modelo de domínio, que é um componente do domínio, e de domínio em si, que poderia ser entendido todo o escopo do problema de negócio a se solucionar.

Consegui me expressar melhor?

2) Sobre a loja virtual.
Quando falo de relevância para o negócio, falo sobre a capacidade de um evento de disparar um novo processo de negócio – e os eventos que constam da Event Store não estão nessa categoria, já que visam, apenas, auditar o estado de um dado modelo de domínio. Os eventos que disparam novos processos de negócio são os eventos de domínio, e estes não são persistidos na Event Store – e posso afirmar que, se estiverem, trata-se de um erro grave. A persistência de eventos de domínio não é necessária, mas ela pode ocorrer em outro repositório que não a Event Store – essa diferenciação é muito importante!

No caso da loja virtual, minha intenção era restringir o escopo ao principal processo de negócio que é a venda de produtos.

Ou seja, ainda que as alterações no estado do carrinho pudessem ter relevância para outros processos de negócio, as mesmas não a tem para o processo de venda – e aí preciso admitir que me expressei muito mal ao omitir detalhes do cenário que poderiam ter evitado essa confusão, vou inclusive editar o texto para deixar o cenário explícito.

Consegui ajudar? Vou melhorar o texto nos próximos dias e espero que o releia e me diga se os conceitos ficaram mais claros. O que acha? E aproveito para te convidar à leitura dos artigos anteriores. Entendo que, partindo do início, as definições sejam mais fluídas.

Muito obrigado pelo feedback e pelas observações. Gosto muito dessa interação porque de outro modo não consigo melhorar a qualidade dos meus textos.

Valeu! :D

 

Oi @Willian, obrigado pela resposta. Hã, olhando em retrospectiva talvez eu devesse ter lido os artigos anteriores primeiro (kkk). Minhas desculpas e obrigado por responder. Sobre a sua diferenciação de eventos que disparam outros processos (e os que não) e eventos que são armazenados (e os que não), creio que entendi o seu ponto, embora pense se isso não criaria uma complicação de design no código 🤔, porque um evento representa uma mudança de estado; e os fluxos subsequentes do programa (disparar um novo processo, como você comentou) dependem dos acontecimentos/mudanças de estado das entidades no programa. E então se diferenciarmos eventos que disparam, digamos, "outras" mudanças e os que só servem para tracker o estado talvez o próprio design se tornasse confuso. Mas é interessante, já que o propósito do event sourcing é de fato tracker as mudanças de estado através de eventos e não disparar mais mudanças; isso é apenas algo que as pessoas decidiram fazer hehe. Então por outro lado ter esses dois conceitos separados como você demonstrou é interessante. Sobre o exemplo do carrinho, acho que só comentei porque o exemplo me pareceu estranho (baseado unicamente na minha experiência pessoal, é claro 😆), mas de todo modo está bem encaixado com o restante da explicação e não é um problema. Novamente obrigado! :)

Fala, Tiago! Não precisa agradecer, é um prazer conversar por aqui.

A diferenciação entre os eventos dos modelos e os eventos de domínio é algo que entendo fundamental, e por dois motivos:

1) Trazer clareza sobre o propósito de cada evento – e aí discordo que a separação adicione complexidade, porque na verdade evidencia a natureza de cada tipo de evento;
2) Evitar que eventos que não sejam relevantes para o domínio sejam disparados inutilmente – algo que geraria um tremendo desperdício de recursos, uma vez que a tendência é haver muito menos eventos de domínio que eventos do modelo.

Como são conceitos diferentes, precisam existir isoladamente.

Espero que acompanhe os próximos artigos, já estamos próximos do fim da série!

Abraço. :)

Code of Conduct Report abuse