🎯 SOLID + Clean Architecture: Projeto completo com NodeJS, Typescript, Express e Prisma

[@rubensl.ferreira1113]

Um vídeo sobre nodejs + ts + prisma + clean arch. e solid é quase uma jóia rara no youtube, e para fechar com chave de ouro já deixou o link do repositório. Você não é um professor, é um prefeito. +1 inscrito 👏

[@vitosnatios]

seu projeto ficou muito bom, vou passar um tempo na repo estudando e assimilando as coisas

[@mentesolta7652]

Doutor muito obrigado por esse aulão 😇😇

[@digransalibian6573]

boa tarde professor! que aula maravilhosa. o prezado tem algum video com fonte do frontend com react axios typescript com solid e clean code? grato! Abraço!

[@doutorwaka]

Olá. Muito obrigado! Infelizmente algo nessa linha para front eu ainda não tenho. Mas vai ficar no radar =)

[@ngungadev]

Valeu @Doutor Waka, acompanhei o video , o bun e elysiaJS, sofri mas aprendi , deu certo como no express mesmo kkkk, obrigado! vou revisar mais sobre SOLID + Clean Architecture

[@doutorwaka]

Top amigo! Que bom que você conseguiu acompanhar!

[@thiago8180]

Muito bom o vídeo, segui a aula codando, todos os passos deram certos, sem erros, parabéns

[@lavdev]

Could yout please explain to me: how to manage relationship between Entity? Many thanks❤

[@doutorwaka]

Hey there! Which kind of relationship are you talking about? Further, are you doubt either at domain level or at repository level?

[@vallento7760]

Sensacional! Eu fiz um projeto em java onde abordei o uso do DDD(domain-driven-designe) e Hexagonal Architecture afim de aprender um pouco sobre. Agora eu voltei para relembrar um pouco de TypeScript e achei esse video maravilhoso. Obviamente vou precisar estudar um pouco o que foi feito, porem para quem tem uma noção basica essa foi uma aula muito boa! Muito obrigado por se dispor a fazer esse tipo de conteudo, ganhou um inscrito o/

[@doutorwaka]

Opa amigo! Que bom que o conteúdo te ajudou! Muito obrigado pelo comentário e pela inscrição! Existe algum assunto que você gostaria de ver aqui no canal?

[@dev.dmsviana]

Ótima aula como sempre, professor. No aguardo de uma aula com o mesmo assunto mas dessa vez com java.

[@cerebeloboladao7190]

Ótima aula, professor. Como ficariam as tratativas de erros no modelo dessa aplicação? É possível fazer usando um middleware do express, ou seria feito usando try catch dentro de cada arquivo?

[@doutorwaka]

Excelente pergunta amigo. Para responder ela de forma satisfatória eu precisaria de um vídeo inteiro. Mas sim, cabe dentro de um middleware. Daria pra pensar em uma estratégia de exception advice. Eu já falei um pouco sobre isso no spring... Aqui no canal o/

[@VictorEmannuel]

Professor, uma segunda dúvida, no caso de um, estou usando esse projeto como um norteador para uma api que realizarei, tirando uma api legada anterior para uma atualizada em node, porem quando vc criou as classes concretas realizando a injeção de dependência percebi que para dois endpoints o número de instâncias foram pequenas, mas no caso de um projeto real que tenha 30, ou 40 endpoints de controladores/rotas distintas, essa seria a melhor forma para implementar?

[@doutorwaka]

Você pode separar ainda em classes/métodos. Por ex, lá no main você chama um "createRepositories"... Que devolve um mapa de repositórios. Daí você chama um "createUsecases" passando o mapa de repositórios e recebe um mapa de usecases... Daí finalmente passa esse mapa para um "createRoutes". Daí vai dividindo de acordo que achar necessário. Em um projeto que estou trabalhando, separei as dependências de cada rota em "providers". Então crio um "rotaXProvider" e passo ela pra factory que me devolve a rotaX. Isso facilitou bastante lidar com as dependências.

[@FranciscoEnderson-k3i]

@@doutorwaka Olá, professor, esse projeto que está trabalhando que implementou essa solução é público? se sim, onde podemos vê-lo?

[@FranciscoEnderson-k3i]

@@doutorwaka Pegando o gancho, o ideal é ja instanciar todas as classes de controladores no main ou apenas quando houver uma requisição para uma determinada rota?

[@JonataSTutoriais]

Perfeito o vídeo, parabéns!

[@doutorwaka]

Muito obrigado! Espero ter contribuído!

[@AnthOo0ny]

Ótima aula, Parabéns! Qual o vscode theme que o senhor está usando ? Grande abraço!

[@doutorwaka]

Eita, eu nem lembro qual eu usava na época.

[@richardwillian3967]

Professor, uma dúvida! Em casos onde eu possuo entidades mais complexas, que possuem um "Relacionamento", por exemplo. Qual a melhor estratégia para converter o "Modelo do Prisma" para a "Minha Entidade" e retornar para minha camada de serviço ? Se eu for fazer um ".with" em cada uma dessas classes, vai ficar algo bastante verboso, eu sempre fico na dúvida do que é melhor... E a maioria dos projetos que vejo por aí, são usados os próprios modelos do prisma, e acho que isso deixa um acoplamento muito grande com o ORM. Outra dúvida, um pouco mais filosófica, como definir qual a melhor forma ? Por exemplo, eu poderia, fazer um "EntitySchemaDto" que teria dependência com o "EntityPrismaModel" e do "EntitySchemaDto" eu converteria para a minha "Entity" Eu poderia fazer uma "Factory" que seria responsável por tranformar o "EntityPrismaModel" em uma "Entity". Enfim, várias formas de fazer, mas como definir qual é a melhor ? Como vc pensa sobre isso ?

[@doutorwaka]

Excelente pergunta e sinceramente merece um vídeo inteiro a respeito. O correto é ter de fato o with nas entidades e conseguir converter o que vier do banco para estas entidades bem como quando for salvar, conseguir converter de entidade para modelo prisma. Utilizaro mesmo modelo para salvar no banco e como entidade do sistema pode ser extremamente problemático a longo prazo. Daqui a pouco lógica de banco de dados e lógica de negócio estarão todas misturadas e será impossível desacoplar. Eu gosto muito de criar mappers que possuem um método estático que consegue converter entidade em modelo e modelo em entidade. Ex: - user-entity-to-user-model.mongo.mapper.ts - user-model-to-user-entity.mongo.mapper.ts Daí no geral esses métodos recebe o modelo e converte em entidade. No caso de coisas bem mais complexas, eles podem até receber mais de um modelo para converter em uma única entidade. Espero ter ajudado =)

[@richardwillian3967]

@@doutorwaka Pô, que legal, professor! Se realmente virar um vídeo seria bem interessante, principalmente essa parte do "o que é melhor fazer ?", parece que não existe uma bala de prata, mas provavelmente existe um consenso na comunidade do que é o melhor. Quanto ao mapper, eu sem querer acabei fazendo algo parecido kk Mas chamei de "EntitySchema". Minha camada do Repositório recebe uma "Entity", e dentro do meu método, eu converto a "Entity" em "Prisma Model" passando por essa classe Schema num método static, "toSchemaModel(Entity)". E, quando quero retorna para a Camada de serviço, faço o mesmo, dentro do repositório, eu chamo outro método static "toEntity(PrismaModel)" que saberá converter para a Entity. É parecido com o Mapper, mas teve outro nome kk Isso que é foda, em Node parece que tudo é certo pq cada um faz de um jeito.

[@doutorwaka]

É bem isso que você fez mesmo. Você fez um mapeador =). A ideia é exatamente essa.

[@dev-isaac-gomes]

poderia trazer um com DDD + clean arch as vezes as vezes fica dificil de encaixar na cabeça como ambos ficam juntos com a entidade sendo baseada no DDD

[@doutorwaka]

Me explica melhor qual é a dúvida. Sua dúvida é em relação a mapear as entidades e objetos de valores e saber onde eles residiriam com clean architecture ou é algum outro ponto?

[@dev-isaac-gomes]

@@doutorwaka minha dificuldade fica no quando iniciar a entidade no sistema e como passar para o ORM pq geralmente podemos ter tipo Address.schema.ts (orm) Address.entity.ts (entidade) as vezes como ambos vão se relacionar ficam meio esquisito de entender é algo que ja fiz mas, não domino 100%

[@doutorwaka]

Entendi. Bom, basicamente você precisa ter um mapeador de entidade para modelo e um mapeador de modelo para entidade. Esses mapeadores vão trabalhar no repositório. Portanto, os métodos do "address.repository.ts" recebem uma entidade, transformam em modelo e mandam para o banco. Na hora de recuperar esse dado, ele recupera um modelo, transforma em entidade e envia para o caso de uso. Dessa forma, o fluxo sempre fica: caso de uso > repositório > banco de dados

[@diegoalvesferreira8481]

Qual o nome da extensão que usa pra parte ali das pastas?

[@Chico6metal]

quero saber tbm

[@doutorwaka]

Acho que é a material icon theme... Coisa assim.

[@caquintella]

Tá bonito isso

[@doisbits145]

ganhou um inscrito pro resto da vida

[@doutorwaka]

Seja bem vindo!

[@raykavin.meireles]

Poderia fazer um outro video usando Golang

[@doutorwaka]

Anotado!

[@SaFeXTech]

Muito bem feito e tudo. Mas eu acho muito horrível, ter que em vários arquivos refazer a estrutura dos dados da entidade novamente. É uma redundância absurda em vários pontos passar de novo e de novo os campos da entidade... Tem de haver uma forma mais simples mantendo os design patterns.