Continuando, para a gente ir arredondando agora, estamos indo para o final já. Aqui essa API que eu criei, ela está com um pouco de responsabilidade demais. Ao mesmo tempo que ela está instanciando coisas, ela está abrindo um serviço, ela está fazendo várias coisas. Então, eu gostaria de separar isso em duas partes. Uma parte vai ser o ponto de entrada, que eu vou cham chamar de main e a outra parte é a API o que fica de um lado e o que fica do outro? vamos lá eu vou copiar isso aqui e aqui tem uma partezinha que eu vou colocar no que eu vou chamar de controller. Então eu vou criar aqui um main controller, e a gente já tem mais um pattern, que é o tal do controller. O controle também acaba sendo um padrão meio amplo, assim, da gente definir. Mas basicamente ele faz com que você conecte camadas diferentes geralmente um driver repassando os dados de entrada tornando a saída de acordo com o driver. Então eu vou receber isso aqui de repente de uma fila, eu vou receber, sei lá, eu até faria melhor aqui, conecta o driver com a aplicação, acho que assim fica até mais fácil. Passando a entrada e retornando para a entrada e saída. Então, normalmente, vou puxar a porta na Adapters aqui rapidamente. No meio aqui você vai ter um controller. Você tem uma API, você tem um controller. Você tem uma fila, você tem um controller. Você tem uma, sei lá, uma user interface, você tem um controller. Então, é essa mediação que vai acontecer ali. E aí, esse controller, qual é a responsabilidade dele? Chamei de main porque eu não vou criar vários, tá? Isso fica mais simples. Então, export the full class main controller. Então, por hora, o que a gente teria que passar para cá seria basicamente essa rota aqui. E aí ele faria esse listen e seria responsável por isso tudo. Mas aqui a gente pode ir um pouco além, que é o seguinte. Todo controller vai interagir nesse caso com algum tipo de HTTP server. Olha o adapter aí vamos fazer duas coisas juntas controller e vamos reusar o adapter o HTTP server deveria me permitir mapear uma rota específica então quando vier um post em barra generate invoices, eu gostaria de ter os params e o body. E os headers. Gostaria de ter os três. É justo, né? Eu vou fazer alguma coisa então, aqui eu vou pegar provavelmente aqui o use case então imagina aqui que a gente vai ter ainda algum use case a gente não sabe quem é eu vou dizer await use case execute base em que com base no body é um post é um post em voice eu sei que é body e eu vou retornar esse output repara só eu não citei mais o express não tem express porque eu vou usar o adapter dele que é o HTP Server. Vamos construir esse HTP Server. Estão fazendo três mexidas, hein? O que todo HTP Server vai ter? Duas coisas. On, que é o mapeamento de URL. Methods de URL. Methods URL. E vai ter que ter algum tipo de callback. Vai ter um listen, certo? E vai ter a porta. Por isso que ele está chorando Pronto E aqui é dois pontos Branas, e tinha os parâmetros também? Não tenho certeza se eu estou falando Ah, não tem, é porque eu não tipei aqui Mas essa é a função de callback Ela incorpora Ah, perfeito Aqui É como se naquela function Tivesse disperso esse callback, ela incorpora toda aquela... Ah, perfeito. Tá vendo? Que aí aqui, é como se naquela function tivesse disperso esse... É o callback mesmo. Perfeito. Exatamente, isso aí. Beleza. Agora que eu tenho a VZP Server, eu vou fazer o seguinte, olha, eu vou ter uma versão de Express pra ele. Espera aí, o que é o Express Adapter, assim como a gente fez o PG Promise Adapter, Export Default Class Express Adapter, Implementos, vamos ter que fazer uma conversão ali. Então, vamos lá. Você vai ver que é bem de boa. Olhar para um lado, olhar para o outro. Olha como ela gerou arquivo para caramba. Vou pegar a API. Depara, hein? Eu tenho que ter esse aqui. Eu tenho que ter esse aqui. Esse aqui é this. Por enquanto, qualquer coisa. E que é o on? App post, então, é, diz app na post, na methods, passando a URL e aqui, ó, assim, é que é essa, ó, mesma função que tá aqui. Agora é JavaScript, né? O que que acontece com o express? ele não sabe o que é o callback ele vai dizer, tem um tal de output aí eu vou pegar de callback que eu não tenho a menor ideia de quem seja e eu vou passar hack patterns hack body e hack headers eu vou fazer um has json output seja json pedido aí já pode falar até de e assim por diante, né? Aqui faltou uma coisa que é esse alguma coisa aí tem que inicializar aqui e aqui é olha como a gente criou um adaptador, um em torno do HTP Server, podia ter uma versão aqui pra RAP, pra Resetify, pra outras coisas, né? Agora aqui ó, aqui isso aqui praticamente vai embora. Aqui a gente tem esse esse tem esse tem essas coisas temos que dar uma refinada lá no controller. Vamos lá, última coisa, hein? Ó, importou aqui. Agora que tem o entrando aqui, não, não é bem né? O então, posso dizer que é igual a e agora, ó, assim como a gente fez do outro lado, pessoal, mesma coisa, ó. mesma coisa, ó. Para dos headers. Seu lugar. Qual é o papel do controller? Pegar de um lado, extrair os parâmetros dos meios que estão disponíveis, nesse caso é uma request, podia ser outra coisa, fila, uma mensagem, passar para frente. Então, estou conectando um driver na aplicação. Esse é o papel. Ele não sabe que é com express. Express não sabe quem está usando ele fechou e agora o main é o final então vamos lá importar todo mundo o meu http server vai ser o meu express vou pegar o meu controle passando o gdp server e o generating voice que é o use case que já está com decorator e vou abrir isso aqui na porta 3.0 pegar o api e vou apagar o que temos aqui agora? vamos lá npx node mon source main subiu bora testar a page qual foi a diferença que a gente fez aqui? usamos três padrões o primeiro deles é o controller para atribuir a responsabilidade de receber de um driver passar para a aplicação, tirando parâmetros, convertendo parâmetros eventualmente. Criamos um adapter para o Express, poderia ter um adapter para outro tipo de serviço, como um RAP. E usamos um outro padrão chamado de Composition Root. Então, mais um aí. Composition Root. O que é o Composition Root? Ele é o entry point da aplicação onde são criadas as instâncias utilizadas pelos componentes. Repara que ninguém sabe exatamente quem é a conexão que está sendo usada. Composition root sabe. Ninguém sabe exatamente qual o tipo de repositório. Composition root sabe. Ninguém sabe exatamente qual o use case, com qual decorator. Composition root sabe. Ninguém sabe quem é o tipo de HTTP server. Composition root sabe. qual decorator, Composition Root sabe. Ninguém sabe quem é o tipo de HTTP server. Composition Root sabe. Então, ele é um padrão antigo e clássico quando você tem esse tipo de sistema. Repara quanta coisa a gente já acabou criando aqui. A gente até pode fazer uma coisa interessante, que é o seguinte, eu vou usar a estrutura de pasta que eu sempre uso. Então, é basicamente domain, application e infrastructure. estrutura de pasta que eu sempre uso. Então, é basicamente Domain, Application e Infrastructure. Em Domain, eu vou colocar aqui o Contracts, as estratégias, eu vou colocar o pagamento, o invoice, né? Vamos colocar o payments, cadê o payments? Lembrando que camada e camada é diferente de pasta, e pasta é diferente de camada. Pasta é só o local físico, né, pessoal? Vamos testar de geral aí, só para ver se eu não estou quebrando nada. Passando, né? Vamos lá, o que mais eu tenho aqui? Main, Presenter, Use Case, eu acho que está tudo aí. Application. Vou chamar aqui de use case. Quem é meu use case? Generation Voice. Está aí. O que mais? Eu vou ter aqui também, eu gosto de botar a interface do repository aqui nessa pasta. Então, eu gosto de botar o contract repository aqui, porque eu entendo que ele está na fronteira eu entendo que o ponto de extensão que é criado é para o use case aqui está a porta que é adaptada pela implementação não no domínio, mas tem gente que gosta de botar a pasta domínio, tranquilo pasta domain vai ter repository também, vai ter o repository database, vai ter uma pasta aqui chamada de presenter, onde eu vou ter o csv-presenter, onde eu vou ter o json-presenter, cadê? Bastante arquivo né aqui vou ter uma pasta chamada http onde eu vou ter keep it simple express, o server vamos lá, pasta database agora com duas coisas aí database connection parece que botou a pasta tudo fica claro né agora com duas coisas aí primeira base connection parece que botou a pasta tudo fica claro pg promise a pessoa acha que o projeto estava bagunçado até ver a pasta depois que ver a pasta fica tudo bom teste só para garantir se não passar agora ferrou decorator decorator é do use case. Então, ó, application. Decorator. Ó, o presenter. Aqui também. Muito fácil era aqui. Logger decorator. Cadê o presenter? Interface do presenter. De novo, é um ponto de extensão da application. Está aí. Quem mais? Quem mais? Factory. Essa Factory é de domínio. Então, eu vou deixar essa Factory lá no domínio. Poderia ter pasta Factory, mas não tem necessidade. Invoice generation strategy. Domínio. Totalmente domínio. São serviços de domínio. Puramente. Controller. Dá para botar aqui no HTTP. Já que ele é um HTTP controller. Use case. A interface use case. Para mim está dentro de useCase. Normal. Rodou os testes. Vamos ver, pessoal. Decorator, Presenter, Repository, useCase, as classes de domínio, Database, HTTP, Presenter, Repository, e o Composition Root aqui na parte principal.