Salve, Deus, beleza? Continuamos essa saga aqui no Domain Dream Design. Agora, na nossa mini saga de eventos, vamos criar um primeiro evento aqui. Eu não quero começar com... Aí que é o problema, né? A gente está falando de evento em relação ao evento que vai ser realizado ali na nossa plataforma e agora acrescenta-se ao evento de domínio. Eu vou tentar fazer a separação para não ficar confuso aqui durante o módulo, para vocês entenderem a qual tipo de evento que eu estou me referindo. Então, nós estamos falando aqui nessa aula exclusivamente dos eventos de domínio. Para a gente poder trabalhar com o evento de domínio, nós vamos gerar uma abstração para poder ter o mínimo de um contrato do que a gente precisa para poder trabalhar com um evento. Então, eu vou criar aqui um domain event .ts Quando a gente não tem uma aplicação de eventos, a gente poderia criar event.ts, mas aí pode fazer a confusão. Por isso que eu estou colocando domain-events para não ter esse devido problema. Então isso aqui vai ser uma interface que vai guiar todos os nossos eventos de domínio. E o que a gente precisa basic, num evento de domínio? Eu preciso saber qual é o ID do agregado que disparou esse evento. Vou colocar tudo no estilo make case aqui. Como a gente sempre está trabalhando com esses IDs como objetos de valores, é por isso que a marcação é interessante, porque importa o value object, ok. Eu quero saber quando que esse evento ocorreu, então eu vou colocar o OccurredOn, que é uma data. Isso aqui já seria o básico para a gente poder trabalhar com os eventos, mas eu vou inserir mais um conceito aqui, que é o EventVersion. Por quê? conceito aqui que o evento version porque à medida que você vai avançando com a sua aplicação os eventos tendem a mudar porque o agregado mudou e aí você está lidando com alguns dados ali na versão 1 e agora esse evento foi alterado, você coloca uma versão 2 ali para justamente os ouvintes desses eventos saberem qual é a versão que eles conseguem lidar. Então, eu vou colocar isso aqui. A gente não vai utilizar para fazer uma amostragem no sentido de trocar a versão do evento para mostrar como um ouvinte lidaria, mas eu poderia ter um método dentro do All20 para ele lidar aqui com a versão 1 ou lidar com mais versões, enfim. Mas isso aqui é interessante para você delimitar ali qual é a versão do evento. Agora, a gente vai chegar dentro dos agregados e fazer o disparo dos eventos que a gente quer. Então, vamos começar aqui pelo Partner ou pelo Customer. Acho que o Customer é o mais simples, se bem que tem o CPF. Não, o Partner é o mais simples porque só tem o NEM. Então, aqui na hora de criar, eu quero registrar um evento. E aí vem duas abordagens que você tem que ficar ligado, que a gente tem mais ou menos duas escolas de pensamento em relação a esses eventos de domínio. A gente tem uma escola que vai querer já disparar o evento daqui e a outra escola que vai querer apenas registrar o evento. Registrar, no caso, vai ser armazenar para que ele seja disparado depois. Quando você olha para o livro do Vernon, ele lida com o despacho do evento no momento que você está fazendo a operação. Inclusive, se você pegar o código-fonte, ele tem um GitHub que ele coloca o código-fonte do livro e etc. Ele faz sempre daqui. Eu não gosto de trabalhar com essa abordagem, vou explicar o porquê. Imagina que você está lá no seu application service, vamos pegar aqui, partner service. Você acabou de fazer o create, e aqui já despachou o evento, vai ter alguém ouvindo e já vai ter alguma execução. Então, numa execução que a gente não espera grandes coisas em relação ao uso de tecnologia, não está usando banco de dados nem nada, vai acabar que vai usar aqui nesse contexto, até passar para a próxima linha, porque o ouvinte já vai ser executado logo de cara. contexto, até passar para a próxima linha, porque o ouvinte já vai ser executado logo de cara. Então, isso aqui tem determinadas vantagens, mas em questão de testes acaba dificultando para você poder rastrear. Então, eu sou da escola eu estou fazendo, obviamente, uma brincadeira, eu sou da escola de registrar o evento. Eu prefiro registrar todos os eventos e no momento posterior, ali no finalzinho do Application Service, que a gente vai fazer esse disparo. Então aqui nós só vamos registrar. Portanto, eu já quero adicionar aqui no meu Gateroot essa parte de trabalhar com o registro dos eventos. Então nós vamos ter aqui um array de eventos, que eu vou trabalhar com set registro dos eventos. Então nós vamos ter aqui um array de eventos, que eu vou trabalhar com set, que é até bom que a gente não trabalha com eventos repetidos, e todo elemento ali do set é um idomainEvent, e aí eu instancio ele aqui sempre, para ele já ter ali o set tudo bonitinho para a gente poder usar. Então, nós vamos ter dois métodos. Um addEvent, que eu recebo aqui qualquer coisa que seja um idomainEvent, e adiciono, e um clearEvent, para que a gente possa limpar isso aqui. Em determinado momento, o agregado vai estar lá cheio de eventos a serem disparados. Quando a gente disparar, é bom que a gente limpe tudo ali, para que, às vezes, alguma outra camada, alguma outra coisa que a gente está manipulando ali, está pegando aquele agregado, não encontre nenhum evento que está ali, isso é para evitar qualquer tipo de efeito colateral. Então, beleza. Uma vez que a gente fez isso aqui, agora, dentro aqui do nosso domínio, nós vamos gerar uma pasta domain events e criar os nossos eventos aqui. Então, eu posso criar, a princípio, um partner-created.event.ts. Então, isso aqui vai ser uma classe que vai ter o mesmo nome, partner-created, e aí ele vai implementar o contrato de idomain event. Então, aqui a gente vai ter que ter a versão do evento. Aqui é como se a gente estivesse trabalhando com uma espécie de DTO, a gente não tem lógica aqui, não tem regras de negócio. Só quero delimitar um objeto para poder abastecer esses eventos. Então, primeira coisa aqui, vou colocar a versão do evento. É um número, né? Vou fixar aqui a versão, que é a versão que a gente está trabalhando. Inclusive, deixa eu até ver se eu coloquei um número aqui. Coloquei, né? inclusive deixa até ver se eu coloquei um número aqui e isso não vai ser... vou colocar um read-on ainda por cima porque aí na verdade nem precisa do public, posso omitir, não quero mudar temos também a data que vai ocorrer e no caso aqui eu quero que ela seja definida no construtor. Então, aqui no construtor, nós vamos receber aqui qual é o ID do agregado. Então, eu vou colocar um read-only aggregate ID. Ele já pegou a mãe aqui. E os outros dados que eu quero registrar nesse evento. Então, eu posso registrar os dados que eu quiser. Como eu estou criando o partner, seria interessante colocar ali todos os dados envolvidos nessa criação. Eu só tenho o nome. Então, vem para cá o nome. Se você tiver outros dados aí nos seus agregados, você vai colocando esses dados aqui no construtor. Aqui a gente não está preocupado em fazer hidratação, coisas assim. Até a gente poderia passar um... Ficar muito grande. Poderia passar aqui um props e fazer a hidratação das variáveis, declarando aqui em cima. Mas, a princípio, é isso. Então, aqui dentro, eu só tenho que gerar a data que ocorreu o evento. Tem mais alguma coisa que ele não gostou aqui, né? Ah, o meu aggregate root, na verdade, aqui é um parten id, que é o id do nosso agregado. Maravilha. Então, está aqui o nosso evento. Tem os dados do evento, o ID que é obrigatório, quando ele ocorreu e a versão dele. Então, dentro do partner, aqui no construtor, a gente vai fazer diferente, porque eu quero armazenar isso aqui e depois fazer um partner add event passando um new partner created com as informações pertinentes. Pronto, está aqui o meu evento. Então, isso aqui só está registrando. Depois, mais tarde, que a gente vai fazer a separação. Então, eu tenho um change name. Como que seria esse evento? É sempre no passado, sempre com o nome informando o que está acontecendo. Então, parted, changed, name. Então, aqui vem o nome no passado e o que a gente está mudando. Vai ser semelhante ao outro que a gente está manipulando também apenas o nome, mas eu poderia ter outras informações. Aqui é interessante porque a gente vai trabalhar com o this, porque aí estou dentro, não é um método estático. Eu vou passar aqui o partner. Change name Foi de bola A gente tem aqui algum teste Aqui na entidade O que ele está chiando aqui comigo Ah, eu esqueci de fazer talvez alguma coisa aqui em relação ao retorno Com certeza, no create, né? Aqui eu não posso esquecer, eu quebrei o funcionamento do método Eu preciso retornar o partner Acho que eu estava dando um erro aqui Então vamos fazer aqui o seguinte Aqui está sendo criado o evento Vou deixar essa criação de evento aqui, mas se eu fizer assim, um partner, engine name, passando qualquer coisa, vamos fazer um console.log em partner, para ver o que vai ter dentro do nosso agregado. do nosso agregado. Deixa eu ver se eu estou rodando aqui, isso aqui é uma SQL, deixa eu tirar essa SQL daqui, para não gerar confusão. Tá, aí vamos rodar aqui o nosso teste. Aquele erro que está acontecendo ali é um erro por conta das coleções do microRM. Como agora a gente está utilizando na parte de eventos, aquelas coleções têm algumas configurações que eles utilizam do mapeamento que é extraído das entidades. E como o microRM não iniciou, ele tenta puxar ali o metadado das entidades e ele não tem. Então, para poder fazer esses testes unitários, a gente precisa dessa configuração aqui, no caso com o próprio Jest, eu criei uma função, ela está aqui na pastinha de testes, a gente vai iniciar o microRM, essa informação aqui é importante para permitir que ele crie a instância dele de forma global, senão ele vai falar que não é recomendado. Passam-se todas as entidades e só essas duas configurações aqui. A gente não vai conectar no banco de dados, continua sendo um teste unitário. Inclusive, o que faz ele não conectar é esse falso que está aqui. Então, ele só cria ali na memória o mapeamento e as coleções funcionam. Então dentro do teste a gente precisa chamar ele aqui em cima. Então fica bem simples. Se eu tiver até uma entidade que não tem coleção, não precisa de colocar isso aqui. Então voltando o que a gente estava fazendo lá em relação aos eventos, Isso aqui. Então, voltando ao que a gente estava fazendo lá em relação aos eventos, vamos ver o que a gente tem aqui na nossa... Acho que eu desativei a console.log de partner. Vamos dar uma olhadinha no que a gente tem lá. A gente tem um evento de criação com o ID do agregado, com o nome, com a versão, e quando ocorreu, inclusive agora que eu vi aqui também, que o nome está errado. Aí eu vou ter que fazer a mudança lá nos dois eventos fazer a mudança aqui e no outro evento também beleza, vamos chegar lá no teste deixa eu comentar dessa partezinha aqui, a gente vai ver que nós temos dois eventos disparados. Então não há uma limitação a quantos eventos um agregado pode ter registrado. Na verdade a gente não está disparando eventos, tem que deixar isso bem claro. Nós só estamos registrando esses eventos. Dependendo da situação, isso também tem que ficar claro, então significa que dentro de uma operação de uma entidade, eu dispare apenas um evento. Eu posso disparar vários. Imagina que eu tenho aqui um objeto, que eu passo ali, e aí tem alguns ifs, e aí se acontecer determinadas coisas, eu quero registrar aquele acontecimento. Então, no final de um processamento ali no Application Service, em uma manipulação de um agregado, eu posso ter uma leva de eventos registrados que eu vou disparar depois. Então, de certa forma, os eventos são bem simples. A gente já tem esse padrão, cria-se com os dados pertinentes, como o próprio Vernon fala no livro, você não precisa colocar todos os dados agregados aqui sempre. É bom que você coloque no mínimo os dados que foram modificados, que foram alterados. Porque isso aí faz com que o seu evento registre de fato os dados ali que deveriam estar nele. Show de bola. Então, vamos evoluindo aqui para a gente poder entender como que vai ser esse manuseio dos eventos. É isso aí, pessoal. Até a próxima.