Deixa eu testar mais algum padrão que eu tinha idealizado. Agora vai ser um pouco mais do mesmo. Tem alguns padrões que eu acho muito legais da gente entender que faz sentido, que pode ser, talvez, possível de utilizar. Então, por exemplo a gente tem use cases aqui como esse deixa eu só rodar de novo esse teste então imagina que eventualmente esse use case ele possa querer chamar outro use case que acho que é a pergunta que eu mais nos últimos anos. Use case pode chamar outro e tal. O que acontece muitas vezes é que outros use cases reagem a este use case. Quando a gente diz assim, um pode chamar o outro, muitas vezes a gente está em um domínio anêmico. Isso quer dizer o quê? Quer dizer que a gente não tem entidades para fazer o trabalho por nós. Por exemplo, nesse caso, eu deleguei aqui a contract generation invoice. Dessa forma, aqui, o contract foi responsável via invoice generation strategy, executou a regra de negócio. Quando a gente não tem esse comportamento, a gente sente mais necessidade. Mas pode ser que você pense assim, sempre que eu gerar os invoices, eu quero mandar por e-mail para alguém as invoices geradas. Bom, pode ser um ponto de vista. Mas não necessariamente eu iria vir aqui e dizer, ah, communication, sei lá, imagina que seja use case, generation invoice, send e-mail. communication, sei lá, imagina que seja use case, generation invoice, send e-mail. Supondo que seja assim, não é bem assim. Eu vou mandar aqui para o Rodrigo, arroba qualquer coisa, o subject é generated invoices, e aí você vai começando a... Claro, os use cases, isso pode tornar esses use cases mais complexos, talvez, e frágeis, quando um muda, o outro acaba sentindo. O que a gente pode tentar fazer em casos como esse aqui? Eventualmente, usar algum tipo de... ou de mensageria, ou de padrão de notificação. E um desses padrões é o mediator. A gente poderia eventualmente vir aqui e dizer, olha, vai ter um mediator aí. Vai ser responsável por isso. Então, vamos pegar aqui os padrões. Eu estou mostrando esse porque eu acho que esse é um padrão que é diferente e vale a pena conhecer o Agitator Observer, qualquer um deles deixa eu pegar aqui qual é a moral dele olha só é um padrão de comportamento que permite que você reduza as dependências entre objetos. Esse padrão faz a comunicação entre objetos, fazendo com que eles colaborem por meio do objeto de mediação. Se você olhar o Observer, é pelo menos a mesma coisa. Define o mecanismo de public subscribe entre objetos permitindo que eles sejam notificados mais ou menos a mesma ideia então cria um mecanismo de notificação para reduzir o acoplamento entre os objetos bom o que esse padrão o que a gente teria aí Eu vou criar ele aqui Agora eu tenho que decidir Mediator O que eu vou colocar nesse medidor Vou fazer um medidor bem simples Então Aqui a gente vai ter Alguns Alguns interessados cadastrados, vamos chamar de observadores. A diferença de Observer e Mediator é que o Mediator é n para n e o Observer geralmente é 1 para 1. Vamos colocar dessa forma. Eu vou ter aqui algum tipo de evento acontecendo vamos colocar aqui algum tipo de callback que seria uma função para ser disparada constructor observers aí deixa eu ver o que ele está reclamando ah tá, faltou aqui o pronto duas partes uma vai ser eu vou ter que me registrar então quando acontecer um evento quem é o callback que eu quero registrar, que é exatamente igual ao que eu tinha em cima. IsObservers push events callback. Basicamente é um registro, tá pessoal? E o notify o publish, você vai ver dos dois jeitos alguém vai publicar um evento associado e aí eu vou dizer para todo mundo que está aí esse é um mecanismo clássico para todo mundo que está observando para todos que está observando aí para todos que estão observando se o evento que você estava interessado é esse vamos fazer o seguinte observer.observer vou executar o callback passando dele e se eu botar um await aqui supondo que isso aqui seja a estrutura do mediator o que é isso? o que é isso? eu vou dizer o seguinte quando eu estiver aqui eu só vou dizer uma coisa uma coisa. Uma coisa só. Até talvez a gente possa usar o resultado do próprio presenter. Faria mais sentido nesse caso. Mas vamos dizer o seguinte. PISMediator. Publish. O que aconteceu? Qual foi o evento? Invoices. Invoices. o que aconteceu? qual foi o evento? invoices generated e eu vou passar o output ponto ele está dizendo para o mundo vocês aí que se decidam o que vocês querem fazer com isso aqui eu vou botar um new mediator só para ignorar para aqueles que não usam o que vocês querem fazer com isso. Aqui eu vou botar um new mediator só para ignorar para aqueles que não usam o mediator. Vamos pela API que acho que pela API vai ser mais fácil. Vamos para o main. O main é o lugar. Então vamos construir aqui. Vamos pensar juntos nisso. Agora eu tenho um mediator. New mediator. Tem que instanciar, né pessoal? Lembra? Mediator mediator, new mediator, tem que instanciar né pessoal, lembra? mediator.on aí claro, talvez aqui não seja o lugar exato para você configurar essa amarração, mas vamos fazer aqui para simplificar Quando tiver isso aqui, function com data, que não sabemos o que é, só dá um console.log em data. Só faça isso. E agora aqui eu vou passar o mediator. Só isso. Vamos rodar aí o teste viu que chegou aqui né agora olha como o mundo é engraçado né imagina que eu tivesse um use case chamado sense email s sei lá sempre que gerar alguma coisa eu queria saber export, default, class, sendEmail constructor coisas, execute vou ter um put depois input depois vamos para o exploit aqui eu só vou fazer um console.log vou fazer uma nada seja input e aí lembra o main é o lugar onde a aplicação é configurada então poderia ter aqui o meu é o sendmail éaja ao invoice generated executando o que estiver na sua responsabilidade eu falei, isso não precisa estar aqui necessariamente, poderia ter algum tipo de lugar onde você faz essa configuração. Isso a gente conecta esses dois use cases sem que eles necessariamente se conheçam. Quem que os conhece? O mediator. Onde que o mediator foi configurado no main? Qual o papel do main? Composition root. Qual o papel do composition root? Entreprenho da aplicação onde você monta o grafo em meses. O plano Composition Routes. Onde você monta. O grafo. Em invenções. A aplicação. A grande sacada é essa. Você ligar coisas que não são conectadas. E você pode usar isso em outros contextos. Por que era um mediator e não um observer? Porque você poderia ter vários eventos aqui sendo gerados por vários objetos e indo para objetos diferentes não é de 1 para N é de N para N tranquilo? beleza