Salve, das Beleza? Continuando essa saga aqui no domínio do Rune Design. Então, vamos construir o nosso primeiro Application Service, que é muito simples aqui, que é o Customer, que a gente já vai entendendo como que funcionam as coisas. Então, esse Customer Service está expondo dois métodos, um para poder listar todos os Customers, e outro para poder registrar esses Customers. Lembrando que o Application Service não é justamente fazer um CRUD. É a operação que o usuário está interessado. Então, às vezes, se é o atualizar, você coloca aqui atualizar. Mas evite de ficar usando esses nomes genéricos ali nas regras independentes. Então, para a gente poder começar listando aqui os nossos customers, se eu tenho acesso ao meu repositório, eu não tenho acesso ao método findAll, eu consigo buscar todos, então aqui pronto, meu listing. Eu não vou trabalhar aqui com filtros, eu poderia receber um filtro aqui para poder listar baseado no critério, fazer a ordenação e etc. Seria isso. no critério, fazer a ordenação e etc. Seria isso. Aqui no register, nós vamos passar dados de entrada. Se eu quero registrar o meu usuário, eu preciso do nome e do CPF. Então, aqui eu não tenho aquele CPF objeto de valor, está vindo de fora. Esses valores vão vir puros. Aí a gente vai trabalhar com aquele conceito de DTO. Os DTOs são muito utilizados para a gente poder passar como parâmetro, porque eles são apenas objetos de transferência de dados. Então, são objetos que não têm lógica, que não têm regras de negócio. Servem apenas para poder carregar as informações e a gente acessar. Posso chamar isso aqui de DTO, de input, ou o que for. Eu vou, na verdade, colocar aqui como input, porque sempre um application service, eu posso passar um input e vai ter uma saída. Às vezes, não necessariamente pode ter uma saída, mas trabalhando nesse modelo que a gente está aqui, a gente vai ter uma saída, nem trabalhando nesse modelo que a gente está aqui, a gente vai ter uma saída nem que seja void. Então, aqui nesse input, eu não vou nem criar um tipo separado para ele. Vou receber aqui o nome e o cpf, que é o string também. A primeira coisa que eu tenho que fazer é pegar o customer. Eu não tenho lá o create. Beleza. Então, eu vou tenho lá o create, beleza? Então, eu vou passar aqui o meu input, como é do mesmo tipo, não vai satisfazer, tenho aqui o meu customer, e agora eu chamo o meu repositório. Então, eu vou adicionar esse Então eu vou adicionar esse customer e no final das contas eu retorno esse customer aqui. Show de bola! Então a gente consegue fazer um teste para poder brincar com isso aqui, a gente consegue. Vamos pegar um teste aqui do... Acho que eu vou pegar o do próprio repositório de Customer, esse aqui que eu copiei, aí eu puxo ele pra cá. Então... Aqui vai ser customer.service.spec.test copiei coisa errada aqui. Acho que eu copiei foi o... devia ter copiado o teste, mas não tem problema. Copia. Aqui está SPECT. Então vamos fazer aqui o primeiro teste, ele deve listar os customers. Tirar todas as importações aqui como lixo. Aí eu já tenho aqui a princípio, eu só preciso do customer, não preciso do customer schema, não preciso de mais nada. Preciso importar mais Kelly Driver e o microRM também. Eu não quero esse debug aqui, ele vai fazer o fork ali que eu tenho. Vamos pegar aqui o nosso repositório de Customer, aqui eu mudo para Aqui eu mudo para custom e repo. Tirar tudo isso aqui para baixo, deixa ali o rm close para ele poder fechar. Aí a gente faz a criação aqui, vou fazer uma criação direto usando a própria entidade. Então vem ali o create, será que ele já vai hidratar para mim com o CPF? Ele hidrata com o CPF, tudo errado, né? A gente percebe que o copilot não sabe calcular CPF. Tanto faz se o CPF está com os dígitos ou não, porque o nosso objeto de valor já vai sanitizar ali. Agora, então aqui vai ser o CustomerAdd, a gente tem que chamar o flush do em. Vou chamar o clear aqui só para poder forçar que ele não tenha nada ali na memória, mas acho que aqui com o findAll ele não pegaria da memória. A gente vai usar agora o nosso applicationService, então vamos criar ele aqui em cima. Eu tenho então o customerService, vai ser igual a newCustomerService, passando a instância do repositório, que é do mesmo tipo do contrato que a gente precisa passar lá, que é o iCustomerRepository. Então, agora, a gente vai chamar aqui o CustomerService.list, que devolve também uma promessa. Vamos ver aqui o que a gente tem de Customer, se isso aqui vai de fato funcionar. Tá. Beleza. Vamos rodar aqui. Olha só. A gente tem aqui a listagem dos nossos customers. Agora, vamos fazer aqui um deve cadastrar ou registrar, né? Sempre o termo aqui é importante, deve registrar um customer. E aqui a gente vai ter um desafio, não sei se vocês já perceberam. Vamos duplicar isso aqui, na verdade, depois eu posso até arrumar um pouco melhor essa questão aqui dos usos dos testes, etc. Não estou preocupado com isso. Vamos fazer aqui a mesma questão depois do fork, eu tenho que pegar aqui, passar para cá, tá? Aqui a gente vai criar, então vou chamar o customerService.register, passando duas informações. Então, aqui eu vou passar essas duas informações no meu serviço que vai registrar. Então, aqui eu tenho o meu customer. Beleza. Mas qual que é o problema que a gente tem aqui no momento? O método add do repositório, ele só adiciona lá naquele unit of work. Ele não vai concluir a persistência no banco de dados. Então, a gente vai ter que fazer aquele flush aqui no final. Quem define a conclusão de jogar lá para a nossa persistência, seja ela qual for, é a nossa camada de aplicação. Porque eu posso ter vários repositórios operando a minha regra de negócio. Depois a gente vai falar mais se é boa prática eu ter vários agregados sendo manipulados aqui para poder persistir. Isso é uma outra história, mas eu posso ter vários agregados que vão ser persistidos. Então, por isso que o repositório não define esse envio lá. É a minha camada de aplicação que define a conclusão. Ela que está orquestrando. Então, a gente não define isso em repositório. Mas a questão é... Espera aí. Então, eu teria que colocar um método flush no repository? Se eu colocar um método flush no repository, não vai ser legal. Porque é ele que vai definir, vai partir dele, na verdade deveria ser aqui uma outra camada para poder fazer essa definição. E aí que vai entrar o nosso unit of work, vai ficar claro do porquê que a gente tem que usar e o que é ele e por que ele é tão importante que ele vai facilitar aqui a nossa vida, pessoal. Então, vamos continuar nossa saga. É isso aí. E até a próxima.