Salve, Deus, beleza? Continuando essa saga aqui no Domain Dreaming Design, na última aula nós criamos o nosso primeiro, na verdade, dois eventos de domínio, e já vimos como que é o manuseio deles. Nós estamos utilizando aquela escola de pensamento de não disparar esse evento logo ali quando ele acontece, mas deixar que ele seja disparado um pouco depois. Então, para deixar bem claro, mais uma vez, o que a gente está fazendo aqui, nós estamos adicionando o evento lá naquele array de eventos, uma abordagem diferente do que está no livro do Vernon, que esse addEvent aqui, ele vai virar um Dispatch. Então, já passa ali o evento e ele já é despachado. Mas como que é feito o controle disso? Lá no livro, o Vernon cria duas classes. Ele cria, se não me engano, acho que é um DomainSubscriber e um Domain Dispatch. Acho que são esses nomes aqui. O Dispatch é justamente a classe que vai despachar esses eventos e o Subscriber vai ficar ouvindo. Esse controle de adicionar ouvintes nos eventos, ou seja, o ouvinte acaba sendo notificado quando o evento é disparado, tudo é feito no Application Service. Então, pegando aqui o Create, que vai acabar gerando um evento de criação do Partner, antes até de começar isso aqui, a gente teria que já ter o nosso Domain Subscriber ativo. E aí que já ter o nosso domain subscriber ativo. E aí ele já vai recebendo os eventos. A gente não vai trabalhar dessa forma. Nós vamos disparar esses eventos na hora de fechar a nossa transação com o Unit of Work. Então o Unit of Work vai nos ajudar com isso. E vai ser legal porque ele tem todos os agregados que foram manipulados. Então, a gente vai fazer o seguinte aqui. No common, nós vamos criar mais uma classe que vai ser o cara que vai gerenciar tanto o registro dos ouvintes quanto o disparar dos eventos também. Isso aqui a gente poderia chamar, normalmente em outras comunidades, quanto o disparar dos eventos também. Isso aqui a gente poderia chamar, normalmente em outras comunidades, a gente chama isso de mediator. O Branas mostrou isso lá no módulo de Solid, aqui do MBA. Eu vou dar um nome diferente para ficar mais claro. Eu vou chamar isso aqui de event manager. Acho que fica um nome mais adequado. Não preciso necessariamente dar o nome do Design Pattern. Então, a gente vai criar aqui o nosso Domain Event Manager. E aí nós vamos ter dois métodos aqui. Um que é para registrar um ouvinte e outro que é para publicar os eventos quando eu vou registrar um ouvinte eu tenho que dizer qual é o evento que eu quero me registrar isso aqui vai ser uma string não vai ser a classe lá do evento específico. Por quê? Porque às vezes a gente pode querer ouvir vários eventos. Isso pode ser aplicável. Então, o que a gente vai usar aqui vai ser permitido usar uma expressão regular. Vamos supor que eu queira receber ou ver todos os eventos de order, por exemplo. Por algum motivo. Não só porque eu quero processar algo, eu posso ter outras necessidades, então passando uma string a gente consegue ter uma variação de quais eventos eu posso ouvir. E o handler, que é justamente o ouvinte, o listener. A gente poderia chamar dessa mesma forma. Eu vou deixar ele como n, mas a gente poderia tipar também, que no final das contas vai ser uma função que recebe o evento. Mas deixando como n, fica mais genérico. recebe ali o evento. Mas deixando como n, fica mais genérico. Já no publishing, o que eu quero publicar eventos. Mas de quem que eu quero publicar eventos? Do agregado. Então vou colocar aqui o aggregate-out, que é do tipo que eu posso tipar, porque eu sei que aqui dentro eu tenho os eventos. Beleza. Isso aqui até poderia virar um contrato, se eu tivesse alguma variação de implementação, mas a gente vai usar aqui o event emitter do Node.js, que ele já tem uma base ali para poder lidar com eventos, vários frameworks utilizam, mas ainda eu vou utilizar uma lib que cria uma camada em cima, que torna esse Event Emitter mais rápido ainda, que normalmente eu uso nas minhas aplicações. Então eu vou colocar assim, Event Emitter vai ser do tipo Event Emitter 2, que é a lib que a gente vai instalar aqui. Então vamos lá. Npm install. Event Emitter 2. Instalou bem rapidinho. Então vamos importar ele ali em cima. Então, no final das contas a gente está usando A base do Node Para poder fazer isso aqui Com o mínimo de Interferência de tecnologia Aí eu vou iniciar o meu event emitter Na verdade está escrito errado Event emitter Vai ser igual a New event emitter vai ser igual a new event emitter 2 passando aqui a configuração do yield card igual a true. Significa que na hora que eu for me inscrever num evento, eu posso utilizar o asterisco para poder me inscrever em mais eventos, criar outra lógica mais apurada. Então, aqui no register, na hora que eu vou me inscrever em eventos, é bem simples. Até o Copilot já entendeu a dinâmica aqui. Eu vou chamar o evento emirer on Passando o evento ali O patter Que eu quero ouvir E o handler E na hora de fazer a publicação Aí aqui a gente vai pegar É, o copilot Tá afiadinho hoje, né Porém ele errou aqui, eu vou pegar o meu Aggregate root Events eu não tenho todos os eventos que foram registrados, então para cada evento nós vamos fazer uma emissão porém eu vou usar aqui o for para cada evento que eu tiver no agregado em questão nós vamos emitir porém aqui tem uma pegadinha nós vamos emitir o evento tem que ser o nome da classe então vou pegar aqui event className vai ser evento constructor .name pra gente poder pegar o nome da classe porém aqui tá errado, constructor aí eu pego aqui o nome da classe em formato de string e passo ela para cá. Mas a pegadinha não é só essa. A gente está publicando o evento no nome dele com os dados dele. Aí eu tenho que considerar que a execução do handler pode ter uma execução assíncrona, pode ter conexão com o banco de dados. Então a gente vai colocar um async aqui. Aqui vai ter que ter um async e um await. Isso aqui é muito importante. Porque se a gente emitir sem esse async e o await, a maioria dos meus handlers, ou basicamente todos, vão trabalhar com promessa. Então, eles vão ser emitidos sendo executados de forma paralela. Isso pode ter consequências que a gente quer que eles sejam emitidos de forma sequencial. Pode ser que a gente queira que eles sejam emitidos de forma paralela, mas aí, então, com essa necessidade, seria interessante que a gente tivesse uma outra forma de publicar que deixasse isso claro. Mas o que normalmente a gente faz é a execução um após o outro. Beleza. Então, é isso. Poderia parecer que era mais difícil, mas é um método para registrar e um método para publicar. A questão agora é como a gente vai usar isso aqui na camada de aplicação para que a gente possa, toda vez que acontecer um processo de negócio, a gente lide com esses eventos. Então, vamos seguindo a nossa saga. É isso aí e até a próxima.