Salve, Deus, beleza? Continuando essa saga aqui no domínio do design, vamos começar a entender melhor, ainda mais, esse balanceamento entre criar um método no Application Service e o que a gente vai usar ali dos nossos agregados. Então, pegando aqui o caso de um update de um evento, basicamente, fora spot e sessão, o que a gente pode mudar do evento? Eu não vou mudar o parceiro. O parceiro é aquele que cadastrou lá o evento. Mas eu posso mudar nome, descrição e data. Então, no update, eu poderia ter esses três campos que são facultativos, consulto o evento, se ele não existe, lanço um erro, e aí aqui eu tenho as três operações sendo chamadas. Isso aqui soa muito estranho para a gente que já está acostumado com a forma ali, ah, eu quero fazer o update, isso aqui demonstra uma regra de negócio muito mais minuciosa. Agora, o que a gente tem que tomar cuidado é que, uma vez que você vê isso aqui, eu não estou querendo dizer que cada campo deve ser alterado separadamente. O que você deve ver é a regra de negócio. E aquilo que eu disse lá atrás, quando você não tem uma regra de negócio definida, você pode deixar os campos separados e depois, quando isso estiver mais claro, cristalino ali, que você tiver mais domínio do domínio, então isso aqui pode mudar, talvez até o nome do evento poderia ser um objeto de valor, que englobaria name e description. Então essas duas linhas aqui seriam transformadas em uma. de valor que englobaria name e description. Então, essas duas linhas aqui seriam transformadas em uma. Às vezes pode ter sentido ali, você tem uma operação, um nome, alguma coisa que você passa que se você está alterando aquele evento ali, você tem que lidar com essas informações e então você passa. Então, essas perguntas têm que ser feitas. Não existe uma resposta certa, uma resposta definida, mas a questão é que quando você começa a colocar update aqui, você começa a ir mais para o lado anêmico, começa a perder expressividade, porque update não fica claro, não deixa claras as intenções do que está acontecendo ali e a gente sempre fica com aquela história de relacionar update com persistência. Então, veja os campos ali que a regra de negócio é preciso fazer tal mudança, precisa receber esses campos, então crie esse método com esses campos. Se eu tivesse também que adicionar a sessão, então, está aqui o método para poder adicionar uma nova sessão, a gente recebe o nome, a descrição ali que não é obrigatória, o total de spots que é obrigatório, o preço e o ID do evento. Eu poderia até colocar o ID de forma separada. E o ID do evento? Eu poderia até colocar o ID de forma separada. Formato, isso aí vai mais de escolha de como você quer trabalhar. Mas a primeira coisa é consultar o evento, vejo se ele não existe, lanço um erro, faço o Add Section, acrescento no repositório e depois faço o commit. Mas lá na criação, lá na criação, eu poderia receber aquelas outras informações para já criar. E já adicionar a seção, pode. Se isso fizer sentido para o negócio. E da forma que a gente está trabalhando, quando a gente tem operações menores, essas operações são combináveis. A gente vê muito que faz sentido o que a gente está fazendo quando eu posso combinar as operações e elas vão resultar aqui no que o usuário vai esperar. Então, como eu tenho operações menores, eu posso criar, vai criar aqui o evento e depois adiciona a sessão. Tudo bem. Aí você vai ter aqui mais inputs ano passado. Essa dúvida aqui é muito comum, então eu acho que isso aqui vai esclarecer muito o que vocês pensam sobre a camada de aplicação. Vamos pegar aqui um caso que seria também uma outra dúvida. Eu tenho lá a sessão, a sessão tem nome e tem descrição também, e eu quero atualizar essas duas informações. Para atualizar uma sessão, eu vou precisar também do ID do evento e do ID da sessão. A primeira coisa também é, faz a consulta. Se não existir, erro. E na hora de fazer a atualização daquela sessão? Eu vou pegar aqui a sessão, buscar ela lá no evento, e aí eu vou chamar um método qualquer, é aqui que está o erro. Não, tá? Se eu fizer isso aqui, está errado, porque você está quebrando essa regra de negócio, permitindo que o section defina esse processo, e é o aggregate root que concentra isso. Então, sempre tudo passa pelo aggregate root. Então, de qualquer forma, a gente teria que ter um método lá dentro. Vamos... Deixa eu pegar esse método aqui que eu tenho ele já. Tenho aqui. Vamos lá para dentro aqui do evento cadê uma classe de evento para eu ir direto vou uma vez aqui aqui então posso jogar essa operação aqui então vamos simular que eu queira atualizar as informações da sessão. Como a sessão é uma entidade filha e ela faz parte de uma coleção, uma forma seria também, sei lá, change name, section name, por exemplo. Seria uma forma de trabalhar. Mas aí a gente tem que tomar o cuidado também para que isso não fique gerando micro-operações que não vão fazer sentido, porque na hora que eu for mudar a minha sessão, vou ter que ir para cada um dos métodos ali, e além disso eu vou receber aqui o ID, eu posso ser mais específico na classe filha, como está aqui, e ter um método no evento que passa as informações para ele. Então, aqui, vou até mudar isso aqui para change, sempre para ter essa mudança de significado. Então, estou mudando as informações da sessão. Eu gosto de trabalhar aqui dessa forma, o change section info, para deixar claro ali que o que a gente quer fazer é mudar as informações básicas. Eu não gosto de colocar changeSession, porque é um nome muito genérico também. Então, vou passar o ID da seção aqui, a gente quer que seja o objeto de valor para ficar mais fácil de manipular as coisas a primeira linha desse método é consultar ali qual é a sessão, se ela não existir já lança um erro, então a regra de negócio que faz parte aqui dentro da própria entidade, aí depois eu verifico, ah, nome está em comando que seria outra forma, tá, mudo o nome lá, description tá no comando, então mudo a descrição. Então veja que nesse caso a especificidade está no filho mas controlado pelo agregante root, pelo pai. Então aqui você pode usar um nome update, o nome da sua entidade ou algum outro nome específico, mas o importante é que você deixe claro a intenção do que você está fazendo. Então, nesse caso aqui, eu teria o meu... Cadê? O meu change... Sex information, passando as informações, e aqui eu tenho que importar o meu objeto de valor. Então eu posso usar o objeto de valor no application service sem problema nenhum para poder gerar um dado que precisa ser passado para cá. A minha classe quer receber esse cara porque a gente já tem uma operação ali que é de mudança, fica mais fácil receber o objeto de valor para poder fazer algumas verificações. Ah, e se eu quisesse buscar somente os spots de uma sessão, também poderia ter um método para isso. Então, aqui seria até um async, recebo o ID do evento e o ID da sessão. Lembrando, aqui eu não recebo o objeto de valor, porque eu não quero que as camadas exteriores saibam que existam esse objeto de valor, que elas têm que manipular, porque isso faz com que as camadas exteriores saibam que existam esse objeto de valor, que elas têm que manipular, porque isso faz com que as camadas fiquem mais acopladas. Tem até uma visão interessante que a camada inferior só deve se conectar, só deve ter conhecimento da camada exterior. Se eu deixo objetos de valores e entidades acessíveis por camadas exteriores, no mínimo que eu fique criando esses objetos lá, quando eu mudar alguma coisa nas entidades, acaba afetando diretamente essas camadas. Então aqui eu vou consultar também o meu evento. Tenho que fazer a verificação se o evento existe. E aí eu quero pegar aqui todos os spots. Poderia criar algum método lá dentro para já devolver isso para mim. Seria uma outra opção. Ou eu posso programar dentro do próprio Application Service também. Não tem problema. Verifico aqui se a seção existe. Tá, existe. Devolvo os spots, que é a coleção. Ou faço uma formatação, se eu não quiser levar isso lá para fora. E a última operação que a gente tem aqui, que é o change location. Então, veja que o location em si é uma operação que é específica porque a gente quer separar ela, quero mudar a localização, quero atribuir um valor de localização para os spots. Deixa eu pegar essa operação aqui também. A operação é mais simples. Então, aqui eu recebo o ID da sessão, o ID do spot que eu quero mudar, pesquiso se a sessão existe, e lá dentro da sessão, o ID do spot que eu quero mudar, pesquiso se a sessão existe, e lá dentro da sessão, eu vou ter um change location também. Então, o filho está controlando a operação do filho dele. A gente pode trabalhar dessa forma também. Cadê o meu change location aqui? Então, vamos pegar aqui. Se bem que o meu change location... Ah, não. Está no spot. Tem que ser no event session. Event session. Aí aqui eu tenho um change location. Então, eu passo o ID do spot, o location em si, pesquiso se o spot existe, se não existe, lanço o erro, e ele faz a mudança. Então o aggregate root orquestrou, e até ele não tem muita noção do que está acontecendo ali por debaixo dos panos. Eu posso colocar essa responsabilidade, não preciso colocar todas as regras no aggregate root porque ele controla. Não, ele pode delegar essa responsabilidade ali, faz muito mais sentido colocar essa regrinha dentro do event session. Aqui eu tenho que importar o id do spot, então eu consulto o evento, tenho que consultar, ou melhor, tenho que verificar se ele existe ou não. Aí tenho os dois IDs, faço a operação, adiciono no repositório. Aí depois... Eu estou pegando aqui a sessão para justamente devolver somente aquele... O objetivo aqui dessa update location é devolver somente o objetivo aqui dessa update location, é devolver o próprio spot. Então aqui estou buscando qual é o spot específico para poder devolver ele como resultado, ou poderia formatar os dados caso eu quisesse. E tem o Publish All, se eu quisesse publicar todos, consulto o evento, se não existe, ok. se eu quisesse publicar todos, consulto o evento, se não existe, ok, publico tudo e salvo. Sempre o repositório nunca tem regra de negócio, só preocupa-se com persistência. Então, o publishAll vai pegar o próprio método publish, que eu poderia também criar um metodozinho dentro do application service para só alterar o public também, mas isso aqui é a regra de negócio mais... será mais usada, mais adequada para a gente poder ver um exemplo. E aí, a gente publica todo mundo. Publica todas as sessões. A sessão vai publicar todos os spots referentes a ela. Está aqui o nosso Event Service. Com várias operações. Já tem uma 168 linhas, mas ele é muito simples também. E aqui dá uma visão de que é a dinâmica, como que é a harmonia de utilização das regras independentes, que elas são combinadas, e a gente vai determinando aqui os métodos conforme faz sentido para os usuários. Então, pessoal, vamos seguir na nossa saga. É isso aí. E até a próxima.