Olá, sejam todos muito bem-vindos a mais uma aula. E na aula de hoje eu vou explicar um pouquinho sobre como fazer um tratamento de eventos. Dentro principalmente do nosso CleanArc ou do hexagonal. Também mesclando um pouquinho não só do conceito de eventos como um todo, mesclando um pouquinho não só do conceito de eventos como um todo, mas como isso também tem a ver com o DDD, com a modelagem de domínio que a gente está trazendo. Então vamos lá. Eventos de domínio, eles podem ser publicados de diversas maneiras. Na comunidade existem três maneiras de publicar o evento de domínio. A primeira maneira é a Publish Right Away, que o Van Vernon mostra lá no livro dele, que é basicamente dentro do seu agregado, ele tem acoplamento a uma interface ou a um método estático que é um domain event publisher. Então, logo que acontece uma alteração, o agregado já dispara esse evento através do domain event publisher. Hoje em dia, não é muito utilizado isso, na verdade, não sei nem se o termo hoje em dia é correto, mas eu nunca vi alguém utilizar isso, tem até alguns evangelizadores que falam sobre, mas nunca vi utilizar porque é estranho, né? Às vezes você fez uma manipulação no seu agregado, mas você nem persistiu aquele estado do agregado. E aí você já publicou um evento e aí quem estiver escutando esse evento vai precisar obter talvez o estado daquele agregado. E pode ser que ainda não esteja consistente, não está atualizado. Ou pode ser que você publicou aquele evento, mas de repente aconteceu algum problema na hora de você persistir o agregado e não foi comitado de fato esse evento. persistiu o agregado e não foi comitado de fato esse evento. Então, tem bastante contras, na minha opinião, essa abordagem de publicar logo que acontece o evento dentro do agregado. Depois a gente tem o Publish After Persistence. Acho que os nomes reais não são esses. Eu criei os nomes agora, né, mas pode ser que tenha algum outro nome específico, mas o Publish After Persistence é basicamente você publicar o evento depois de persistir, né, então você, lá na sua, na implementação do seu repositório, por exemplo, você persistiu, o seu agregado garantiu que comitou a transação e aí você chama manualmente, depois, o domain event publisher publicando todos os eventos agregados após a persistência. outra que o pessoal, que a comunidade levanta nesse cenário é que fica muito aberto ao acaso, ao lembrete da pessoa que for implementar o repositório lembrar de chamar esse método de publishEvent, que normalmente fica dentro do agregado. Então, se você não chamar esse método, pode ser que você tenha um bug no sistema e os seus eventos de domínio nunca sejam enviados. E também não tem uma garantia certa de que os eventos são enviados, porque se de repente, depois que você persistiu a informação, deu algum problema na comunicação do seu domain event publisher com o broker, ou, sei lá, se é um se você está lidando com eventos internamente e essa aplicação recebeu um shutdown não tem a garantia de que esse domain event de fato chegou em quem deveria chegar, então também é um outro conto o terceiro approach, o approach que eu vou ensinar pra vocês aqui no livro é o publish through persistence é basicamente é usar a camada de persistência pra gente persistir junto do agregado os eventos de domínio e aí depois obter estes eventos de domínio lá da camada de persistência do nosso banco de dados através ou de um job ou de um mecanismo mais sofisticado como um Change Data Capture, que é o CDC. Eu vou ensinar para vocês como obter através do job e do job publicar ou já consumir esses eventos e utilizar, chamar os casos de uso, etc. Ou publicar em algum outro broker necessário o CDC, na minha visão o maior problema dele é que você precisa de mais customização, de coisas mais fora da caixa, você precisa ligar por exemplo um Golden Gate ou um Kafka Connect que tem um Golden Gate que vai separar esses eventos para o Kafka mas aí você já fica acoplado ao Kafka é mais sofisticado é muito interessante porque evita que tem um Golden Gate que vai separar esses eventos para o Kafka, mas aí você já fica acoplado ao Kafka. É mais sofisticado, é muito interessante porque evita com que a sua aplicação tenha que ter algumas regras que não deveria ter, mas a composição traz as suas outras complexidades. Então, por isso a gente vai fazer via job para vocês entenderem. Domain Inventor Publisher e Keyless Gateway. Então, esses dois caras são basicamente interfaces Que podem existir São ou gateways ou interfaces No caso do hexagonal, você mais encontra Domain Event Publishers No CleanArch, você encontra mais como Queues Gateway, Invoice QE Gateway, Customer QE Gateway, Customer News Gateway. Então, dependendo da arquitetura que você está, você vai ver mais um tipo de padrão ou mais um outro. E dependendo também se você, por exemplo, não está usando algo como o Domain Events Through Persistence. Você nem precisa de um gateway efetivamente como este. Bom, na verdade, o que eu ia falar sobre tratamento de eventos é isso. Então, aqui estão as principais formas de você produzir eventos através do seu domain model. Da parte do consumo de eventos, não tem muito segredo. o seu domain model. Da parte do consumo de eventos, não tem muito segredo. É um framework driver, então é um Kafka listener que você configura o Kafka, por exemplo, que vai ter o consumidor do Kafka e você normalmente configura uma interface adapter como um Kafka listener que vai pegar o que está vindo, vai converter para o seu caso de uso e vai passar para frente. É a mesma coisa para um RabbitMQListener. Não tem muito segredo nesse ponto. Ou então, às vezes, você nem precisa ter um listener, você só expõe uma API REST que algum broker push-based vai puxar o evento para você. Então, é isso. Espero que vocês tenham gostado. Vejo vocês na próxima aula.