Olá pessoal, sejam todos muito bem-vindos a mais uma aula. E vamos mudar a continuidade aqui, a extração dos casos de uso. A gente já está quase tornando os controllers da nossa aplicação, os adapters da REST API e do GraphQL, algo bem bacana. Agora falta o último controller, que é o do evento aqui, que tem bastante acoplamento aqui. Então a gente vai corrigir esse cenário ou melhor, a gente vai extrair, vamos tirar do controller, vamos deixar esse controller fininho essa adapter fininha do jeito que deve ser e depois a gente até pode fazer os testes dos casos de uso aqui que ficaram sem testes porque a gente está garantindo uma cobertura grande, uma cobertura integrada e broad através desses Controllers, no escopo do teste bem expansivo, mas a gente também deve criar casos de uso unitários aqui para eles. Então é isso que a gente vai fazer agora. Então vamos lá, vamos primeiro, vamos ver aqui ó, caso de uso de criar um evento, caso de uso de comprar um ticket. Vamos começar com isso aqui ó, com o caso de uso de criar um evento. Então vamos lá, create event, use case, extends use case, algo e algo, e a gente sabe que esse algo é na verdade um public record input e tem o output. Show de bola. Então aí a gente traz aqui o input do create event e o output do create event e aí aqui ó final final pá pá pá a gente vai fazer alguma coisa aqui com esse cara que é basicamente um trazendo aqui do gto, trazer do controller para cá acoplamento com o partner service e acoplamento com a dependência event service DTO, vamos ver o que tem nesse DTO aqui id, name, date, total spots e tem acoplamento com o DTO do partner então vamos dar um leve tapa aqui vamos lá vamos começar input vai ter um string date vou deixar como string aqui não como a data porque justamente o formato da data quem deve dizer é o domínio ou caso de uso pode ser que mude é então vou deixar como string mesmo. Name, então é nome do evento, nome do evento, e total spots. Int, vou pôr aqui, integer total spots. E também tem o lance do partner ali, então vou colocar aqui, mn ali, então vou colocar aqui MNOP. Então, Long Partner ID. Beleza. E aí ele retorna o evento como um todo, só que a gente vai retornar uma cópia simplificada do evento. A gente não precisa retornar tudo do evento. Então a gente vai retornar a data o nome, o id do partner o long id do evento acho que o partner o total spots, até besteira nem vamos retornar o total spots vamos retornar isso aqui mesmo show de bola o name também nem precisava, mas ok não vai vai fazer diferença aqui para a gente. Então vamos trazer aqui as dependências, partnerService, privateFinalEventService, vamos colocar aqui na ordem o TOC, vamos adicionar aqui o construtor com os dois parâmetros. Final e final. Objects.requiresNoneNull. E objects.requiresNoneNull. Beleza, então já temos aqui as nossas dependências. Aqui, input.date. as nossas dependências aqui em put ponto de it input ponto nem me impute total spots aqui em put ponto partner id e aí se forem que a gente pode retornar na verdade um validation exception já conhecemos bem é e ok só tem um detalhe aqui que até dá pra ser um pouco mais otimizado esse código talvez pra alguns a legibilidade não fique tão boa mas a legibilidade não fique tão boa mas vamos fazer de um jeito que fica boa seguinte o que a gente vai fazer aqui ó não vai ter aqui é if present se for presente event 2.7 partner Se não Ele vai Passar por esse runnable aqui Que é basicamente Isso aqui E aí, o que acharam? Tá legível? Aí a gente pode identar E aí ele vai quebrar pra linha de baixo Então, se existir valor, vai setar Se não, ele vai passar por aqui Que vai nascer uma exception E aí, basicamente event é igual a isso aqui return new output então event.getid, event.date, event.name e aí vamos colocar aqui só pra input.partnerid ao invés de lá. E, beleza, tem um detalhe aqui que é string, só que ao invés de eu ter que ficar formatando a data de novo, já que eu formatei lá em cima e está uma data válida, então eu vou simplesmente pegar do input e devolver. Ok? Pelo meu toque, esse cara a gente também poderia pegar do input e devolver mas vamos deixar assim vai que vai que passou por alguma tratativa, foi tratado esse nome pode ser que tenha sido tratado então ok, extraímos esse caso de uso, agora vamos para o próximo que é o op próximo Que é o Opa Que é o Subscribe, vamos lá Na verdade está escrito subscribe, mas É Ele na verdade é o comprar ticket Né Buy ticket É Buy event Ticket vai chique é bairro event ticket vai ver se é ruim né vamos fazer o seguinte o ok é que tem de use case que vai ter um input e um output public record input e o output input vamos lá ver o que é de input que eu já não me lembro tem um id do evento e o id do customer então vamos colocar aqui long event id long customer id e aí ele vai retornar o tal do ticket event dto id, partner é meio ruim né esse retorno, vamos devolver o id do ticket e o status ok não vai fazer diferença pra gente, então long ticket id é string ticket status e aí o nosso caso de uso input output implementar esses caras vamos lá copiar tudo isso aqui trazer pra cá beleza vamos começar então adicionando as dependências do jeito que está depois a gente vai voltar e corrigir a parte das dependências então priority final event service que mais que tem só esse dependência ok adicionar o construtor opa adicionar construtor com os dois parâmetros já então beleza final final o objeto require no isso aqui já estão comendo com farinha já sabe de cor né beleza agora aqui as tratativas né tratativa a gente já sabe como é que a gente vai tratar o new validation reception esse aqui ó throw new validation exception, esse aqui, throw new validation exception, throw new validation exception, throw new validation exception também, isso aqui, throw new validation exception, event not found, beleza, o que a gente pode fazer aqui agora e esse maybe customer aqui com get get ta meio mal utilizado vamos fazer a versão shortcut a versão shortcut é o seguinte é customer or else get customer or else get ou melhor, or else throw or else get, or else throw isso aqui e aí input customer id bem melhor, agora a gente já tem o customer aqui, a mesma coisa por eventos não é pro evento então é em ponte e venda e de orel se trouxe new e aí mata isso aqui e mata isso aqui. Bem mais enxuto. Bem melhor. Maybe ticket is present. Ou seja, perdão. Se o ticket já tiver sido comprado, ele vai lançar uma exception. Então, vamos lá. Como é que a gente pode tornar isso aqui melhor? Na verdade, é input.eventid input.customerid e aí a gente nem precisa do maybe ticket ou precisa do ticket? não, não precisa saber do ticket então vamos lá é basicamente o if present é ter a gente não vai usar ter a gente vai outro o new excepção aí tem uma validação aqui de regra de negócio é se o evento ponto total spot por menor por menor que ele em tickets pontos.size mais 1, sold out. Ou seja, ele já vendeu tudo. Ok. Tá, beleza. Então, aqui, ele está basicamente gerando o ticket, adicionando o ticket à lista do evento e salvando. Vamos deixar assim por enquanto. É do jeito que está, do jeito que vai ficar. e salvando vamos deixar assim por enquanto é do jeito que está, do jeito que vai ficar new output com o ticket.getid e event.getid, não, e ticket.getstat status.name .get status.name .get status.name .get status.name .get status.name .get status.name .get status.name .get status.name .get status.name .get status.name .get status.name .get status.name .get status.name .get status.name .get status.name .get status.name .get status.name .get status.name . eu tenho certeza, acho que o Hibernate talvez não vá atualizar o ID do ticket na lista por isso acho que pode ser importante a gente... bom, se bem que se a gente fizer isso aqui eu acho que ele não vai atualizar o ID do ticket na lista aqui, então o que a gente vai fazer? esse cara retorna um optional de ticket. Mas na verdade, para simplificar, event id, eu vou mudar. Vamos retornar o id do evento mesmo. event.getid e o status do ticket. E a data da reserva. Vamos fazer essa mudança aqui. e a data da reserva, vamos fazer essa mudança aqui string na verdade é um local, um instant reservation date e aí a gente vai pegar ticket.reservedAt aí tá bom, show de bola vamos fechar, vamos fechar, vamos fechar, vamos fechar vamos fechar vamos fechar vamos fechar agora já viu no controle agora vamos substituir esses caras aqui ó quem quer aqui new create event use case passando o event e o partner service final var use case igual use case ponto execute new input e aí é o date name partner id e total spots então dto.date dto.name dto.getspots, ah é o partner né, dto.getpartner.getid e total spots. E só tem um detalhe aqui assim, o partner ele pode estar nulo aqui né, quem garante que está sendo enviado corretamente? isso aqui pode dar um null pointer feio na nossa cara então a gente... vamos ver se o próprio IntelliJ ele faz alguma verificação, mas não faz então vamos fazer o seguinte colocar aqui em cima agora ele fez não fez long partner id aí esse cara objects requires no null esse a gente até pode colocar aqui partner is required e aí final var partner id aqui, beleza assim a gente garante que a gente não vai receber um null pointer de cara aqui output na verdade ele retorna o evento ali vão mudar pra retornar o ao tipo tcheca que é que é basicamente a gente fazer isso aqui retornar ao tipo tcheca é por hora não vai fazer diferença pra gente na layer de adapter ter esse cara, que a gente deve retornar o output que a gente deseja mesmo, não estou trabalhando mais com o simples conceito de CRUD, poderíamos ret você tornar uma instância do evento completa é um evento de ti ou poderia é precisa necessariamente retornar aí é o negócio aí que você está expondo que que vai precisar dizer normalmente até que até que a gente retorna assim de fato então é o cliente e vence por exemplo está tornando a idéia de neymar e id do partner, que é o que ele basicamente tem, id, name date e o partner id, ah faltou o total spots né, eu acho que eu pulei, esse cara falou que não era importante mas vamos colocar aqui ó, total spots input.total spots agora sim ele vai estar bem parecido com o nosso event. E eu não vou retornar ticket, não vou retornar a instância do partner completo, porque não cabe ao meu serviço, no meu REST API de event, retornar esses caras que são nested, que também são outros agregados. Então eu vou retornar só isso, só os atributos raiz do meu event. Aqui a mesma coisa, aqui a gente vai então, final var useCave e esse cara é basicamente o customer service e o event service final var output igual a new useCase igual a new não né, useCase.execute new input e aí é id e o dto.customerId. E a gente vai dar um return nesse cara aqui mesmo. A gente até pode fazer assim. Na verdade é response.enche.ok. E faltou o querido trycat, né? ok e faltou o querido trycatch né faltou os nossos queridos trycatch porque sabemos que esse cara lança possivelmente um validation exception então é um processable coisa né então vai que a gente vai deixar o excepção de ter um responsivo quanto a pessoa se abrange o ponto x.net message e aqui o responsivo E aqui, responseEntity Disso daqui, acabei mudando um pouquinho Opa Esse cara aqui Final var Out Put E aí return responseEntity. Vamos fazer do jeito que a gente está fazendo com os outros Então, yuri.create, barra, events, barra, mais, output.id, ponto body, output, no fim, essa rota nem tem, mas ok. Então, alteramos o nosso event controller, o que o event controller é? Adapters. Uma layer de adapter. E a gente não fez o GraphQL ainda para ele. Então, na próxima aula, a gente faz o GraphQL para o Event. E também vamos fazer os testes unitários de todos esses nossos queridos casos de uso que a gente está fazendo aqui. É importante. E novamente, vamos rodar todos os testes da aplicação para garantir que está tudo passando e não quebrou nada. Vamos ver se não quebrou nada. De fato, o partner continua passando. Event continua passando. Customer, getCustomerById, createCustomer. Os testes da application Então todos passando Bem bacana Isolamos toda a nossa regra de negócio Para dentro de casos de uso Que são muito mais semânticos Inclusive esse aqui Faltou o final UseCase Fizemos o CreateEvent UseCase, deixamos até o código mais bonito SubscribeCustom o createEvent useCase, deixamos até o código mais bonito. SubscribeCustomerToEvent, ficou até um pouquinho mais bonito algumas coisas, mas a regra continua a mesma. E aí depois a gente vai voltar para trabalhar dentro do hexágono, para deixar ele melhor, tirar essas entidades anêmicas. E depois vamos trabalhar a parte das portas de saída do hexágono. Então é isso. Espero que vocês tenham gostado. Vejo vocês na próxima aula.