Salve, beleza? Quase finalizando a nossa saga de domain design, agora vamos continuar aqui em cima do application service, mas não somente nele, mas também vai entrar a questão de relacionamento entre subdomínios. Pegando o caso que a gente viu aqui na aula passada, vamos supor que a gente tenha um application service mais genérico que acaba satisfazendo a necessidade de vários usuários diferentes, ou esse admin event service aqui. Aí a gente chega lá num método qualquer e ou via um serviço que eu tenha na minha aplicação, de autenticação, de autorização também, ou às vezes eu quero passar um usuário aqui como parâmetro com outros dados. E aqui eu quero verificar assim, ah, espera aí, esse usuário é o de mim, então ele não pode, não está permitido para poder fazer essa ação. Isso aqui está correto? Para a gente poder responder essa pergunta, a gente tem que voltar àquela modelagem dos domínios. Nós temos eventos, autententicação parte de e-mails parte de tickets eu posso colocar isso aqui dentro do meu subdomínio não vai aparecer a polícia federal na minha porta é o que eu costumo falar mas quando a gente começa a colocar esses conceitos aqui de role admin, nós estamos fazendo um vazamento de domínio. São conceitos que estão na autenticação. Inclusive, o Vernon mostra... É no livro do Vernon ou do Evans? Eu acho que é do Vernon, que ele mostra que... Não, é o do Evans que mostra isso. Ele mostra que a equipe vai fazendo a modelagem dos domínios e eles resolvem inserir esses conceitos de autenticação ali no meio e eles começam a ver que fica complicado gerenciar tudo isso. Tem como se fosse um corpo estranho ali no nosso contexto do limitado. Essas questões de autenticação elas não precisam ficar dentro do nosso application service a não ser que você tenha um bom motivo para isso o seu application service ele já está disponível ali partindo do princípio que o cliente dele é um administrador. Ele não quer verificar isso. Eu poderia ter em conjunto o contexto de autenticação, validando isso antes de uso desse Application Services de Administrador, que poderia ser lido nos próprios eventos. O que isso significa? application service de administrador que poderia ser lido dos próprios eventos. O que isso significa? Significa que eu poderia chegar aqui no meu controlador de eventos e fazer a integração com a minha autenticação de um subdomínio que eu fizesse, inclusive se eu quisesse colocar aqui dentro, a gente não vai fazer isso, mas poderia ter uma pasta de autenticação e autorização aqui com todas as regras. Aí eu faço a integração com o nest, então eu poderia colocar aqui, ó. Ah, tá. Na verdade, tudo isso aqui, vamos supor que fosse admin. Então, role admin. Pronto. Então, a minha proteção, olha que interessante, a minha proteção olha que interessante, a minha proteção ela a minha autenticação ela não está acoplada com o meu evento e nem o meu evento com a autenticação mas as duas estão trabalhando aqui em conjunto pra poder formular a minha regra de negócio, que eu tenho que executar mas eu tenho que garantir também que somente a pessoa autorizada vai fazer aquilo. Eu posso ter application set de autenticação, de login, etc., de autorização, e aí eu uso aqui os decorators, uso o meu framework, eu uso o módulo do seu framework. Mas aí quando a gente olha para o application set, você não tem essas preocupações de usuário, você vai se preocupar com a sua regra de negócio, isso é vazamento de domínio. Cuidado para não fazer essa mistura, porque toda vez, agora na hora que a gente mexer com alguma coisa de autenticação, acaba impactando diretamente os nossos agregados. E a gente não quer isso, a gente está fazendo separação dos subdomínios justamente para poder separar a resolução de problemas. Então, na maioria dos casos, a autenticação é fora, a não ser que você tenha um bom motivo para isso. Deixa eu até matar isso aqui. Deixa eu matar isso aqui também. Show de bola, pessoal. Então, vamos para a última aula aqui do módulo. É isso aí. E até a próxima.