Salve, beleza? Continuar essa saga aqui no domínio do Green Design. Eu acho que uma dúvida que a gente pode começar a ter ao criar esses Application Sets e a relação deles com os agregados é qual que é o tamanho desses métodos, se eu devo criar um método para um método do agregado, a gente vai esclarecer isso nessa aula. isso nessa aula. Então, eu peguei aqui o próprio Customer para poder mostrar um exemplo de um método que ele poderia receber vários dados e acessar vários métodos do agregado de Customer. No momento, a gente só tem o Name para poder fazer a modificação, mas eu poderia fazer sentido, eu poderia ter um método update dele, em que eu recebo o ID para saber qual o customer que eu tenho que atualizar, e o nome que é facultativo. E eu poderia receber aqui em outros campos referentes a esse customer. E a gente teria um cenário semelhante a esse, e também poderia se organizar de outras formas também. Mas eu recebo essas informações, elas são facultativas, eu não quero atualizar todo mundo, então eu verifico se tem um Name e faço uma modificação. Antes disso, claro, eu tenho que fazer a consulta ali do repositório. Então, toda vez que você precisa do agregado, a primeira coisa é ver se ele existe. Inclusive, a gente poderia fazer aqui um se não customer, chamar um erro. Pronto, não tem. Esse tratamento de erro pode ficar aqui na camada de aplicação e também se estender ao seu framework, porque provavelmente o seu framework que você vai usar tem alguma camada de centralicação e também se estender ao seu framework, porque provavelmente o seu framework que você vai usar aí tem alguma camada lá de centralização de tratamento desses erros. Se for HTTP, você vai pegar esse erro e converter para um determinado status code e até fazer alguma formatação de mensagem. No final das contas, a gente faz o edge e depois o commit. Então, essa aqui é a lógica de um update. Então, quando a gente tem essas operações dentro dos agregados que elas são bem concisas, elas são coesas, a gente não está criando com aquele pensamento de banco de dados, elas podem ser reaproveitáveis. E isso vai ser bem legal no uso do agregado de evento. A mesma coisa eu fiz aqui para o partner. Então, eu tenho lá o ID e o name. Não é obrigatório, mas se for passado, change name. Inclusive até daria para poder fazer uma verificação aqui, que se eu não tiver o name, não precisa nem chamar a unit of work, nem nada. Eu simplesmente devolvo, para poder devolver um erro, que eu não tenho nenhum dado para atualizar, ou simplesmente já devolver o partner. Então essas regrinhas, elas fazem parte desse contexto aqui. A gente está orquestrando todos os componentes para poder operacionalizar as necessidades do usuário. Vamos pegar aqui agora um serviço do evento. Então, vamos fazer assim. Event Service. serviço do evento, então vamos fazer assim eventService aí aqui onde tem customer eu tenho que tomar o cuidado com pegar o maiúsculo aí agora posso fazer a modificação bem rapidamente e agora onde tem customer minúsculo, vira Event. Pronto, já importou a linha. Agora a interface aqui, eu não sei se está realmente correta. Vamos pegar aqui a interface do evento. E aqui ficou errado, mas é só a gente mudar... os lugares adequados. A gente não tem muitos métodos. Então aqui... evento também. então aqui event também e restou aqui esse... eu posso mudar tudo de uma vez? ficar só event, pronto o que ele está achando aqui comigo? Ah, aqui é evento repo. Então, se eu quiser listar todos os eventos, eu tenho ali um list. Agora, eu não registro um evento. A gente cria um evento. Então, eu vou fazer aqui a mudança. Mas, para criar esse evento, qual é um dos dados que nós vamos receber aqui, que vão nos guiar? É o Partner ID. A gente vai receber ele no formato de string. Ele vai vir, o usuário que vai usar, vai passar ele de qualquer forma que for, e vai chegar aqui como um ID. Então, a primeira coisa seria o quê? Usar o repositório de Partner. Então, a gente vai precisar desse cara aqui também. Então, vamos lá. Construtor aqui vai ficar em várias linhas. Aí a gente importa aqui o Partner repo que é o IPartnerRepository. Então, a primeira linha que a gente vai fazer aqui, antes de tudo, é preciso pegar o Partner até ver se ele existe. Isso é muito importante. Então, se o Partner não existe, simplesmente um erro vai ser lançado aqui pela nossa camada de aplicação. Agora, se o Partner existe, lembra lá que a gente criou aquele método do initEvent? Faz todo sentido, não faz? Porque agora eu tenho que passar aqui a data. Então a gente tem uma data aqui da criação. Então aqui um date que é do tipo date. Eu estou passando esses tipos diretamente aqui, eu poderia criá-los de forma separada, trabalhar com aquele conceito de DTO, e poderia ser inclusive, no caso JavaScript, até uma classe que a gente poderia fazer algumas validações primárias. Então aqui vai ser input date tem o name também que é input name, tem mais um dado faltando que é o a descrição então aqui vem o input description e como ele não é obrigatório, eu posso definir ele aqui como facultativo com interrogação aqui uma string ou até um nu. Na hora que eu for alinhar isso aqui, ele vai descer tudo para a linha de baixo. Pronto. Então, isso aqui me devolve o evento. E do evento, nós vamos usar o repositório. Pronto, então, o unit of Work organizou tudo aqui. Se eu tivesse outros agregados e etc., o commit iria fazer a nossa criação. E se eu quisesse, o que seria uma outra operação interessante aqui para a gente poder ir abrindo a mente com esse application? Eu posso querer, às vezes, consultar só as seções do meu evento. Eu posso ter um método assim? Posso ter um método assim. Posso colocar aqui, find sections, e a gente passaria aqui o ID do evento. Então, event ID. E aqui que vem a questão. Quando a gente olha para isso aqui, peraí, eu quero buscar os eventos. Ou melhor, eu quero buscar as sessões. Eu vou retornar aqui do meu repositório event session? Não. Toda vez que a gente busca pelo repositório, sempre nós queremos lidar com o agregado. Então, eu pego o agregado de eventos, aí eu vou retornar event.sessions. Depois, obviamente, que eu fizer um await aqui e um async aqui. Pronto. Eu tenho aqui as minhas sessões. Beleza, vai retornar lá a coleção. A gente consegue converter para array e tudo mais. O retorno do application service também tem vários tipos de mais. O retorno do Application Service também tem vários tipos de pensamentos na comunidade. Próprio Evans quanto Vernon não gostam de expor a entidade em si para as camadas exteriores, ou seja, o framework. Então eu poderia fazer aqui um tipo um mapeamento, eu pegaria todas as seções aqui e converteria para um objeto simples, para não expor justamente para as camadas exteriores não usarem as entidades e não haver esse vazamento de domínio, esse termo é muito utilizado, mas tem outras pessoas que preferem. Eu sou da seguinte opinião, que você tem que avaliar se os seus dados que vão ser retornados para o usuário são muito diferentes do seu próprio domínio. Às vezes, vale a pena você utilizar porque é muito simples e você está criando mais uma camada de apresentação que você poderia ter. Então, já fique ciente que essa camada pode existir e tem os benefícios justamente para você poder ter as preocupações de como você vai mostrar esses dados. E essas preocupações não ficam na application service. A gente vai simplesmente retornar aqui as informações. Quem está consumindo que vai formatar esse negócio aqui. Então, se for um web, um GraphQL, se virem aí para poder formatar essas informações. Além disso, a gente poderia ter outras informações aqui. Na próxima aula, eu trago outras operações para a gente poder abrir a mente, mas aqui no caso do evento, fica bem claro que toda vez que a gente está abrir a mente, mas aqui no caso do evento, fica bem claro que toda vez que a gente está manipulando aqui, é sempre o evento. Ah, eu posso consultar aqui a sessão para alguma coisa, eu posso pegar o meu evento, pegar uma sessão específica para poder verificar alguma informação, mas sempre quando eu estou consultando aqui, é sempre o evento todo. Eu quero o agregado, ele protege a consistência, as invarianças do nosso projeto. Então, pessoal, é isso aí. E até a próxima.