Salve, das maneiras! Continuamos essa saga aqui no Domain Dream Design. Agora vamos fazer os restantes dos endpoints da nossa API REST. Eu já trouxe aqui o que a gente precisa fazer em termos de controllers. Então, resta ali a parte dos eventos e a parte das orders. Então, nós vamos fazer um certo desenho aqui da API REST e aí vai ficar bem claro que a API REST não deve ter uma influência nos nossos Application Services. Na verdade, a gente tem que fazer o desenho dela como for conveniente utilizando de forma mais adequada esses Application Services. Vamos pegar primeiro o EventsController. A primeira coisa tem que estar registrado lá no módulo de eventos para que ele seja utilizável. Então, nós vamos ter aqui um events utilizando o application service. Inclusive inclusive isso aqui a gente vai ver depois deixa eu até tirar essa parte daqui então nós vamos poder listar os eventos e criar um evento e publicar todo mundo, deixa eu ver se eu tenho um método aqui para poder listar tudo, eu chamei ele de list, né e aqui poderia até fazer o return direto para poder listar tudo, eu chamei ele de list, né? E aqui poderia até fazer o return direto. Quando a gente começa a ter muitos métodos, como é o caso aqui, do nosso application set, ele tem vários métodos de busca. Mudar isso aqui para um nome tipo Find Events, como a gente tem Find Sections, fica mais adequado. Então, eu vou trabalhar dessa forma. Então, eu tenho uma rota Get, um post para poder criar, e aqui eu estou utilizando um DTO, porque a gente tem várias informações que eu não queria colocar ali. E aqui já vem uma dica para quem estiver trabalhando com o Nest, você pode usar duas libs, inclusive vou até utilizá-las aqui, que é o Class Validator e o Class Transformer. Essas duas libs vão te ajudar tanto a validar dados das requisições como a serializar esses dados. Tem uma camada de serialização ali na resposta. Criar o DTO dessa forma aqui permite que a gente faça as validações. Eu fiz isso justamente para que quando se passe uma data ali na request, a gente precisa da data no formato do JavaScript, então passando esse type aqui em cima desse date, quando é passado ali um iso na requisição, ele vai converter já para o date e eu passo ele para o application service. Então já é uma transformação bem simples que é feita. E aí a gente tem aqui os outros dados, é o nome, descrição, ID do partner, e a data está aí. Então a gente coloca ele dessa forma que o nest vai criar a instância desse event.to se a gente fizer uma coisa lá no main. A gente tem que chegar aqui e fazer o seguinte. App.use.global.pipes. Aí a gente vai ativar aqui o validation pipe. vai ativar aqui o validation pipe. E agora tudo vai ser... Qualquer regra de validação que eu quiser utilizar ali, etc. Lembrando que quando a gente está falando de validação, nesse contexto aqui de uso do DDD, são essas validações primárias que a gente pode fazer ali na request. Validações mesmo de negócio, elas ficam dentro dos agregados, dentro das entidades. Mas nada impede que eu veja se um campo foi passado ou não, porque eu não preciso ficar acessando necessariamente o meu serviço. Na parte de publicar todos, eu passo o ID do evento, publish all, como a gente está modificando os registros. o produtall, como a gente está modificando os registros, então estou utilizando um input, até poderia ser um patch aqui na verdade também, aí seria questão mais de semântica, chamamos lá o produtall, passando o evento e pronto. Então aqui nós temos essa primeira parte. Vamos brincar com ele aqui para ver se está ok. A gente vai chegar aqui. Então, eu já tenho alguns partners que a gente criou no HTML. Inclusive, eu tenho que rodar aqui a aplicação, senão eu não vou conseguir fazer o meu teste. Maravilha. Então, agora vamos consultar aqui um partner. Vou pegar esse primeiro aqui. Eu posso colocar essa variável do meu arquivo porque aí eu não preciso preencher daqui pra baixo inclusive esse partner aqui ele está aqui em cima mas está sendo utilizado aqui embaixo mas é até bom ficar perto do partner que a gente já coloca aqui o ID. Então, está aqui o ID. Aí, na hora de pegar um evento, ou melhor, pegar um evento, não, pegar todos, não tenho nada, e na hora de criar, a gente vai passar aqui todos os dados. Veja a data no formato que a gente está passando, inclusive com esse timezone, poderia ser aplicável, nossa plataforma está sendo acessada por pessoas do mundo inteiro. no formato que a gente está passando, inclusive com esse timezone, poderia ser aplicável. Nossa plataforma está sendo acessada por pessoas do mundo inteiro. E aqui a variável está sendo utilizada, não preciso ficar passando ela. Então, vamos lá. É a primeira prova de teste aqui para ver se tudo isso está funcionando. Se a gente criar aqui e ele retornar. Então, tem alguma coisa que faltou aqui. A data, na verdade, que está indo nesse formato, então tem alguma coisa que eu esqueci. Ah, esqueci de uma coisa lá no main, que não basta fazer isso aqui, eu tenho que falar para ele que o transform é igual a true. Para ele pegar, por exemplo, eu passo um número que é string no meio de uma requisição, se o meu DTO, se o meu objeto aqui de dados falar ali que ele é inteiro, então ele vai converter do string para inteiro. Então isso é bem legal, essa segurança que a gente já tem aqui, tudo vai de forma direta sem que a gente tenha que se preocupar. A princípio ele tentou fazer a criação lá certinho, mas nunca as coisas rolam de primeira, principalmente coisas mais complexas. Tá aí, conseguimos criar o nosso evento ó o partner ID aqui que nós adicionamos mais complexas. Conseguimos criar o nosso evento. O Partner ID que nós adicionamos lá em cima. Show de bola! A data também está aplicadinha ali. Agora nós temos aqui um novo evento. Vou colocar o ID dele aqui embaixo. E agora vamos para a parte da sessão e a parte dos spots. Porque quando a gente olha para o Application Service, como que a gente vai fazer o desenho da nossa API para poder fazer esse consumo? Eu separei um controller, nada impede, você não tem que fazer tudo num controller, porque está tudo no application service. Inclusive, eu poderia gerar outros application services separados também para as operações que são mais focadas na sessão e nos spots, mas se eu fizer o desenho de ter um nested endpoint, ou seja, seja sempre vou me pautar aqui por um evento no id barra sexo isso aqui é o nosso recurso então sempre vou depender do id e cabe muito bem com tudo que a gente tá fazendo porque se eu quiser pegar todas as sessões eu recebo o aí disso aqui é pegando parâmetro de rota tá só tiver um parâmetro de rota tanto aqui quanto aqui, eu pego dessa maneira, então consulto as seções, crio uma nova seção, aí tem ali o Bory com o Name, Description, Total, Spots e o Price, que a gente já viu aqui, poderia passar um DTO, mas aqui não tem nenhuma transformação específica, aí se chama lá o AddSession, já retornando aqui direto. Eu tenho também um método para poder fazer o update, a gente não tem lá um UpdateSection, que nós simulamos ali algumas atualizações, então temos esse formato de API usando o application service integrado diretamente com ele. Eu poderia ter um outro desenho de API se eu quisesse, lidando apenas com a section passando o ID do evento às vezes até assim. Esse é outro modelo, não estou aqui para julgar qual que seria adequado, eu prefiro o alinhado porque ele diz que eu vou trabalhar sempre com esse evento e eu quero ver as sessões, a gente vai trabalhar sempre com as sessões, deixa muito claro. Então vamos pegar aqui a API, a gente já pode consultar aqui, eu coloquei o ID do evento correto, se eu consultar não tem nenhuma sessão, então aqui a gente já pode consultar aqui, eu coloquei o ID do evento correto se eu consultar não tem nenhuma sessão então aqui a gente vai abrir uma sessão lá eu coloquei um spot, então olha só ele já retornou todo o spot bonitinho isso aqui tudo foi criado no banco de dados se a gente consultar somente as sessões veio somente o objeto session e section, na verdade, e os spots, não veio os dados do evento. Então, eu vou pegar aqui o id, na verdade, da section, eu não tenho outra sessão. Eu tenho uma outra variável aqui também que a gente vai passar eu consigo fazer outras operações aqui pra baixo com a questão dos spots mas vamos ver se a gente consegue publicar o nosso evento como um todo estou fazendo um publish all e é retornado o próprio evento então tem o evento, a section e o spot. E teria todos os spots aqui. Então, se eu tivesse mil spots, esses mil spots seriam retornados aqui também. E aí, você fala assim, ah, eu preciso retornar tudo isso? Aí é uma outra preocupação. A gente tem um agregado, que inclusive está saindo lá do Application Service. Se você não quiser trafegar por vários motivos todos esses dados, não é necessário. Simplesmente abstraia. Então perceba que nesse caso o Application Service serve tanto para API REST, GraphQL ou qualquer cliente, qualquer cara que queira se comunicar com a nossa aplicação. Se você quer lidar com menos dados, a responsabilidade é sua e não do Application Service. Então, a gente colocou aqui o ID da section, ele já está publicado, esse aqui é só para poder fazer o update, eu não quero brincar, quero brincar aqui com os spots. Vamos ver se a gente consegue pegar os spots. Eu peguei o spot. E aqui eu consigo atualizar. A informação do spot também já está ali. Vamos dar uma olhadinha aqui no controlador de spot para ver se tem alguma discrepância. Veja, toda vez é o Event Service. Mas aqui já tem um endpoint alinhado de segundo nível, porque eu tenho que passar o ID do evento e o ID da section. Tem um método findSpot para a gente poder consultar todos, eu recebo dois parâmetros de rota para poder fazer a consulta. Se eu quiser fazer a mudança lá do updateLocation, veja que na API REST a gente não tem esse update location. Eu tenho um put que eu passo as informações. Se fosse específico, se eu tivesse um outro tipo de atualização, aí eu poderia colocar aqui um sufixo nessa rota para trabalhar com essa notação. Ah, eu tenho aqui um location no final, senão algum outro nome. Foi de bola. Então, vamos dar uma olhada aqui. Show de bola. Então vamos dar uma olhada aqui agora nas orders. Vamos ver se a gente consegue consultar as nossas orders, que a gente não tinha consultado lá nos testes. Show de bola. Aqui está faltando um detalhe que eu tenho que passar um card token deixa qualquer coisa aqui eu tenho um compara, eu te gostei da sugestão token visa eu tenho que pegar aqui o ID de um spot, porque senão posso usar esse endpoint aqui eu quero fazer a reserva desse lugar o customer ID eu só não tenho certeza se a gente colocou o correto aqui, mas a gente faz a consulta não estava correto não ia dar erro então passo para cá, fujo de bola, então ele vai usar o Customer ID, o Section ID, o Spot ID, mais o evento ID que está sendo passado na URL. Então, vamos criar aqui e pronto, conseguimos criar a nossa reserva. Deixa eu tentar fazer aqui a criação novamente. Não fiz tratamento de erro, mas vamos ver aqui o erro que ele vai acabar lançando. Spot not available. Aí eu poderia usar aqui a camada, para quem se interessar, de Acception Filters do Nest para poder fazer esses tratamentos de erros. Mas só para poder fechar aqui essa aula, vamos fazer um docker exec masql bash para poder avaliar o que a gente tem no banco de dados. Nós temos, vamos lá fazer um select, asterisco from orders vamos colocar aqui events.orders eu não tenho como assim não existe show tables ah não é order, é order na verdade como assim não tem tem que ter olha eu criei a order lá bonitinha e a gente tem o spot reservation. Então, spot reservation. Está aqui também, em relação. Um detalhe que até a gente não se preocupou muito, mas observe o nome dos campos, que você pode mudar se você quiser. Observe o nome dos campos, que você pode mudar se você quiser, mas a forma como a gente vai criando ali a nossa linguagem ubíqua, determinando no design tático entidades, os nomes dos campos, etc. Quando a gente olha para cá um Customer ID ID, a gente pode até achar ruim a princípio, mas isso aqui fica claro já, de cara, que tem objeto de valor envolvido aqui. Tem objeto de valor que está aqui. Então, transferir também essa linguagem para o banco de dados, ajuda também até o pessoal do banco de dados a entrar nessa roda toda do DDB. Então, tente manter essa linguagem o máximo possível no nome de tabelas, nos nomes dos campos, porque aí o nosso projeto inteiro, lembra que o projeto é o código, o código é o projeto, e o banco de dados também faz parte disso. Show de bola! Então, conseguimos fazer aqui toda a nossa integração nós temos a nossa aplicação funcionando com o NestJS construída com o DDD. Então pessoal, é isso aí e até a próxima!