Salve, beleza? Continuamos a saga aqui no Domain Dreaming Design. Na última aula, nós criamos o nosso gerenciador de eventos, aqui o nosso Domain Event Manager. E agora, nós vamos fazer a integração aqui com os processos de negócio. Então, vamos imaginar o seguinte, que o partner foi criado, registrou-se o evento de criação. Aí tem algum listener ali que vai receber esse evento, vai fazer algum processo também de negócio. Então, isso deve acontecer antes do commit. Deve ficar aqui antes desse commit aqui, porque se tiver alguma mudança no banco de dados, deve ficar aqui antes desse commit aqui, porque se tiver alguma mudança no banco de dados o Unit of Work também encabeça mescla tudo e executa lá no banco de dados e a gente não vai ficar publicando não vai ficar registrando isso diretamente em cada Application Service porque, poxa, toda vez que eu quiser gerenciar esses eventos, vou ficar fazendo alguma coisa aqui. É interessante que a gente delegue isso a um outro tipo de serviço. E a gente vai trabalhar aqui com um conceito bem interessante que vamos imaginar que esse nosso application service, ele tem um ciclo de vida. Ele vai ser iniciado aqui, eu estou falando no caso do método, eu vou iniciar esse processo de negócio, ele vai dar certo ou vai falhar. Então, eu poderia tanto fazer aqui uma abstração de um Application Service, ou até gerar um serviço, que é o que eu vou fazer para deixar o nosso Application Service mais livre. E aí vai ficar claro exatamente o que eu vou fazer. Então, esse Application Service vai ficar aqui na camada de aplicação, como ele vai ser usado pelos outros Application Services, somente, então, é na camada de aplicação aqui do common. Então, a gente vai criar aqui uma classe chamada de applicationServices. E o que a gente vai precisar aqui, né, para poder lidar com essas brincadeiras todas que a gente vai fazer no construtor, eu quero receber o unit of Work, referência ali da nossa interface, e o Domain Event Manager, que é do tipo Domain Event Manager. Vamos imaginar um ciclo de vida do nosso processo de negócio. Eu tenho o acontecimento quando ele inicia, quando ele finaliza, que eu vou colocar como finish, e pode acontecer um fail. Tá? E pode acontecer um fail. Então, o que a gente vai acabar fazendo aqui? Ao invés de importar, o unit of work ainda pode ser importado nos nossos application services, mas a gente vai importar um application service aqui, que é do tipo application service. Então, aqui, no começo, eu vou chamar o meu application service start. Depois, aqui, um application service finish. Tiro o unit of work, tiro ele aqui de cima também. E aí, se acontecer algum erro, eu poderia lidar ali com o fail então esse application service aqui ele pode fazer logs e fazer outras coisas, ele está lidando com o ciclo de vida do meu processo de negócio tá eu não tenho nada no momento para colocar no start, então eu vou até aceitar a sugestão dele aqui de fazer o ignore do slint aqui pra ele. No fail também eu não tenho. Fica a imaginação de vocês por conta aqui da nossa aplicação. O exemplo mais simples eu não tenho. Mas no finish que está aqui o nosso grand finale. O finish que vai ter o commit do Unit of Work, então aqui tem que ser async, e aqui que eu vou fazer a publicação dos eventos. Então a primeira coisa que eu tenho que fazer aqui é pegar todos os agregados envolvidos nessa transação e o Nut of Work tem isso. Então nós vamos adicionar aqui mais um método, a nossa interface, que eu consigo de aggregate root Isso vai fazer com que a gente tenha que mudar aquela implementação nossa Então aqui ele vai exigir que eu implemente esse método implement aqui, vou passar ele lá para baixo e a gente tem que pegar todos os nossos aggregate roots. Do entity manager nós conseguimos pegar aqui todas as é no entity manager ou no unit of work? É no unit of work mesmo. É no EntityManager ou no UnitOfWork? É no UnitOfWork mesmo. Eu consigo pegar todas as minhas entidades que foram... que estão gerenciadas, que é esse PersistStack. Ele vai devolver aquele... Ele vai devolver um set na verdade, e tem outro que eu preciso pegar que é getRemoveStack. Essas duas aqui a gente já consegue fazer o nosso trabalho. Aí, se eu colocar elas num array... Vou colocar o REST Operator aqui. A gente consegue concatenar tudo num lugar só. aí ele vai cheiar aqui que eu não tenho um array de aggregate roots, agora eu tenho fiz o casting aqui, maravilha aí agora voltando lá para o nosso application service eu vou pegar os meus aggregate roots aggregate roots, aggregate roots vai ser igual aos aggregate roots. Então, para cada aggregate root que eu tiver no meu array, vou pegar o meu domain event manager, publish, o meu domen event manager publish o meu gregate root e aqui eu tenho que tomar cuidado porque aqui é await porque aí ele vai publicar os listeners com relação àqueles eventos ali vão ser executados de forma sequencial aí vai para o próximo agregado, inclusive os listeners que podem manipular, os nossos handlers que podem manipular os agregados ou até os mesmos agregados, eles podem adicionar mais eventos ali, então um listener pode publicar um evento de domínio que um outro listener também pode ouvir, tá? Beleza. Então, aqui no nosso create, eu teria a wait aqui e a wait aqui. Até que, nesse caso, a nossa operação está pequena e a inserção disso aqui não iria atrapalhar a legibilidade. Eu estou mais preocupado com a legibilidade. Mas se a gente tivesse aqui um método run também, seria interessante eu vou até aceitar a sugestão do do co-pilot. Eu posso fazer um run que eu recebo aqui um callback, que eu posso retornar uma promessa com um resultado e aí é retornado aqui na execução do run, essa promessa que o callback vai executar. Então logo aqui em cima eu posso fazer um disstart com a wait, faço ali um try, tenho aqui o resultado, deixa eu ver se ele vai me dar aqui o resultado, vai, aí se acontecer um erro qualquer, a gente chama um fail e depois estoura o erro. Então aqui fica com async. Então fica mais elegante a gente usar o run, a gente pode chegar aqui e fazer um run, vou chegar aqui e fazer um run, aí eu tenho um async aqui, abre e fecha isso aqui, e eu passo para cá. Então aqui no caso eu não preciso disso, retorno aqui direto e retorno o partner. retorno aqui direto e retorno o partner. Então é como se eu estivesse processando o meu negócio dentro desse run aqui. Então eu posso fazer a mesma coisa para o update também. também. Então, que eu não preciso mais do unit of work, que ele vai acontecer, o commit dele vai acontecer no finalzinho aqui, e que eu não preciso mais desse await. Isso aqui não é obrigatório, se eu estiver trabalhando com uma consulta, pode ser que eu queira trabalhar com um ciclo de vida da aplicação, que eu tenho logs, eu tenho outras coisas lá. Mas sempre quando a gente vai trabalhando com uma persistência, é interessante colocar isso aqui. Maravilha, pessoal. Eu quero ter um pouco mais de tempo para poder brincar e ver isso aqui acontecer. A gente já fez essa integração, já criou aqui esse Application Service. Na próxima aula, a gente faz o teste de fato, fazendo a integração disso tudo. Então, vamos continuar nossa saga. É isso aí e até a próxima.