Princípios SOLID em uma API REST com Node.js e TypeScript | Code/Drops #44

Muito se ouve falar sobre arquitetura, princípios, design patterns e vamos combinar que, na maioria das vezes, são temas extremamente chatos e maçantes de estudar, concorda?

00:00 - Fala Dev
01:19 - O que é SOLID?
08:03 - Criando uma API com SOLID na prática
44:27 - Testando a API no Insomnia
45:42 - Considerações finais

-----

Acompanhe a Rocketseat nas redes sociais:

Inscreva-se na nossa Newsletter!

Ouça também:

[dieegosf]

Fala dev! Os conceitos apresentados no vídeo são uma adaptação dos conceitos mais tradicionais utilizados há decadas dentro da programação e não são apresentados como um resumo de livros de arquitetura ou design patterns.

A ideia do vídeo é mostrar como eu aplico os princípios de forma adaptada dentro da construção de APIs com Node e não simplesmente estipular regras para seu código, por isso, alguns conceitos podem não bater 100% com os mesmos apresentados em livros de SOLID, clean code ou DDD.

É normal que cada pessoa e time adapte cada estrutura para sua realidade e não simplesmente saia utilizando de regras sem entender a motivação por trás de cada uma delas.

Bora codar 🚀

[mathws]

Sim! Seriam interessantes videos sobre CQRS, DDD e Clean Architecture com node e typescript

[RodrigoMedeirosBrazil]

Agora a Rocketseat tá indo pra um caminho que faltava, arquitetura de software! isso foi muito bom, se continuar eu curto e compartilho, sei que dá muito trabalho, e por isso, parabéns!

[kildersonsena]

Fala Diego, beleza?! Primeiramente eu quero parabenizar a Rocketseat por investir esforços para esse tipo de conteúdo, pois na minha visão nós sempre temos que incentir o povo a construir bons softwares e arquitetura + SOLID são ÓTIMOS assuntos para essa galera. Porém, eu queria fazer algumas considerações em cima de algumas coisas que foi falado que não condizem com a Clean Arch. Vou citar aqui:

- 03:09 - OCP na minha visão e experiência é sim um princípio super importante, ainda mais se tratando de Backend. Eu não sei se você compreendeu o real sentido dele, e nem julgo se não tiver entendido, mas acho um pouco leviano dizer que ele não é um princípio importante ficar de olho;

- 15:35 - acho que aqui foi erro mais grave se falando da Clean Arch. Entidades fazem parte da camada mais interna da arquitetura e elas NUNCA devem depender de NADA ao redor dela, e aqui você "marretou" uma biblioteca de terceiro dentro da entidade User. Acho que deve ter dado um pequeno derrame no Tio Bob hahahahaha (zuera). Poderia nesse caso criar uma interface da mesma forma que você fez com o serviço de Email. Na MINHA visão, essa lógica de geração de ID de um entidade deve ser resolvido a nível de Repository;

- 19:06 - eu não conheço essa convenção de "package by feature", mas se você está baseando sua aplicação em cima da Clean Arch o controller não deve nunca ficar na camada de use case. Controllers pertencem a camada de Infra (como você mesmo fala no fim do vídeo) ou em uma camada de Application em algumas implementações, mas que no fim das contas ele acaba virando um braço de Infra e a camada de Use Case pertence a uma camada mais interna. Nesse caso eu criaria um diretório Application (ou algo do tipo) e colocaria todos os controllers lá.

- 46:15 - aqui você falou certo, que todo mecanismo externo (detalhes) tem que está totalmente abstraído e elas "não devem conhecer" as regras de negócio diretamente. Porém você infrigiu exatamente no pior local para infringir, que foi sua entitade User.

Mas mano, fora isso o vídeo está muito bom. Espero que você receba esse comentário como uma crítica construtiva e que te motive a melhorar em algo, até pq arquitetura de software é algo muito interpretativo. Ah, to aberto pra debater aqui para ajudar geral =).

PS: de repende um post, vídeo mais aprofundado sobre isso seria top. vlw =)

[Bruno-wbwu]

0:21 - Fala Dev
1:19 - O que é SOLID?
5:47 - Palmeiras não tem Mundial
8:03 - Criando uma API com SOLID na prática
44:27 - Testando a API no Insomnia
45:42 - Considerações finais

[fabioramatis]

O conteudo que eu mais queria ver aqui! Muito obrigada mesmo, vcs sao incriveis

[KevinMadalossoVeiga]

Esse é com certeza um dos melhores conteúdos sobre SOLID que tem no YouTube. Obrigado Diego por compartilhar com a gente esse conhecimento. Abraços!

[jeffersonferreira]

Se falasse uma vez por semana sobre arquitetura seria perfeito, pode ser vídeo longo que dá nada, o importante é aprender.

[mentaah]

Cara, Diego você é um MONSTRO. Seus vídeos andam me ajudando demais, desde quando eu era estagiário e agora como Júnior. Comecei a ver mais de princípios SOLID e arquitetura DDD e você tem me ajudado demais com as explicações. Você está de parabéns pelo ótimo trabalho e conteúdo!

[vanilsonnog]

Gostaria de acrescentar outro ponto aqui também. Não sei se vai ficar tão claro, mas vamos lá. Antes de tudo, quero parabenizar a vocês pelo conteúdo excelente!
Em 42:20, onde ele ta "injetando" as dependências do Repository e MailProvider. Seria interessante mostrar isso sendo feito por algum injetor de dependências próprio, fazendo que com fosse mais simples e direto de modificar as dependências de um conjunto de Repository por exemplo. Da forma que está, cada repositório precisa ser injetado manualmente e pode acontecer um erro de o desenvolvedor importar uma implementação de repositório que faz as coisas de outra forma (tipo, em uma linha ele importa o PostgresUsersRepository e em outra linha ele importa o MySqlPermissionsRepository).

Usando uma implementação mais bacana de injeção de dependências resolveria. Seria mais ou menos assim: suponha que você tem 2 implementações possíveis de repositórios, uma para Postregres e outra para MySQL. Aí digamos que os Repository de Postregres estarão na pasta e os de MySQL estão em "(...)implementations/mysql". Usando um injetor de dependências, bastaria que você mudasse uma configuração (a config que diz qual diretório de implementações será usado) e aí você rapidamente passaria a usar outro conjunto de repositórios, tudo isso alterando minimamente ou nem sequer precisando alterar o código do injetor, . :)

[YagoFernades]

Eu tenho uma interpretação um pouco diferente do princípio de aberto/fechado. Para mim se usa o princípio de inversão de dependência para alcançar o princípio de aberto/fechado.

Por exemplo, vamos supor que estamos fazendo uma calculadora, então implementamos as 4 operações básicas (+, -, x, /), para isso recebemos como parâmetros a operação que vai ser realizada e os números que vão ser calculados, com um switch, por exemplo. Essa funcionalidade não está em acordo com o princípio de aberto e fechado porque qualquer operação nova que queiramos introduzir teremos que modificar a classe ou função, mas ao invés de recebermos como argumento uma “string” simbolizando a operação a ser realizada, recebêssemos a própria função poderíamos adicionar quaisquer outras funcionalidades que precisemos sem ter que alterar a classe/função original, logo seria aberto para extensão e fechado para modificação.

O exemplo é meio bobo, mas acredito que ilustra bem o princípio de aberto e fechado.

[YagoErnandes]

Faça mais vídeos de arquitetura, por favor! Eles são incríveis!

[Rafael_Tecnologia]

caraca a sua didatica e excelente, estou cursando pos arquitetura de software, comprei o livro clean arquitetura, mas vendo seus videos ficou bem mais claro, já virei inscrito!

[rogerfernando]

O conteúdo técnico desse vídeo é sensacional!

[rafaelhirooka]

Ah, feedback top a seguir:
Diego, os tipos de vídeos que mais me atraem no canal são de arquitetura, by far!
E gosto que vai direto ao ponto, sem lenga lenga hehe

Valeu!

[henriquealmeida]

Por favor, mais vídeos como esse! Chega um ponto em que temos que nos atentar a melhorar nossas estruturas de código e não apenas as tecnologias a serem usadas. Muito bom o vídeo!

[danielcarvalho]

Durante toda essa semana, eu estava procurando muitos conteúdos na internet sobre isso. Li várias explicações, assisti muitos vídeos, mas nenhum deles possui a didática fantástica de vocês. Agradeço!

[marciodeandradesena]

Já subi de level só com esse vídeo aí. Valeu de mais galera

[gamaquad]

O conteúdo é extrema importância, para mim inclusive que tenho "toc" de organização seja estetica ou funcional do código mais videos como este me satisfazem de várias formas.

[felipebarcelos]

Fantástico! Isso era exatamente o que faltava para ser ensinado. Parece que a Rocketseat lê mentes.