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 🚀
amigo, posso sugerir o canal do eximia co, ele aborda esses conceitos, apesar de usar c# os conceitos são bons ...eu tenho aprendido muito com o Elemar jr
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!
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
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!
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!
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 "src/repositories/implementations/postregree" 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,. :)
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 =)
Fala Kilderson, eu também tive alguns "alarmes" soando em relação a algumas colocações do Diego, mas as suas também merecem cuidado! Primeiramente, minha principal crítica ao apresentado pelo Diego é sobre quando ele disse que "SOLID não dá para aplicar no front, onde temos que seguir mais as decisões do framework" - acho bem errada a colocação hahah Os princípios não dizem em nada que só se aplicam a back-end. Basicamente ele usou algumas libs (express, mail, db) e separarou a lógica de negócio desses periféricos. Isso é bem possível de se fazer no front, mas acho que pra maioria das pessoas falta um "guia" de como fazer. No back temos as receitas de bolo controller+repository+model+services que já engessam, ou ajudam, as pessoas a pensar em desacoplamento, enquanto no front esses padrões não estão tão estabelecidos. Sobre a sua crítica a usar um gerador de ID na classe User, eu acho que você está sendo radical e perdendo o sentido num preciosismo. Afinal, qual o limite de "código de terceiro" que não pode estar na camada de domínio? Se eu quiser usar um HashSet da vida no meu modelo, vou ter que importar essa classe. É um código de terceiro também. Então se javascript tivesse um uuid generator "nativo" ele poderia ter usado diretamente? A linha é sutil né. Eu acho que o seu ponto é na verdade para termos cuidado com código terceiro pois ele pode mudar facilmente ou ainda oferecer uma api que traga complexidade desnecessária para o domínio. Agora, se ele confia que a uuidv4 é uma lib estável e vai apenas usar 1 função dela, é mais simples apenas usá-la como ele fez. Criar mais uma IUUIDGenerator e uma implementação concreta que chama a lib para apenas 1 método e depois ter que ficar injetando isso sempre que se criar uma entity vai deixar o código mais complexo e mais difícil de se trabalhar! E sobre gerar o ID no repository: tem casos mais complexos, por exemplo quando se deseja criar entidades relacionadas (manja aggregates?) que vão exigir algumas idas e vindas ao repositório desnecessárias. Posso bolar um exemplo caso esteja interessado. É isso. Valeu por trazer a discussão e valeu mais ainda ao pessoal da Rocket pelo conteúdo de alta qualidade!
@@viniciusneto6824 Hahaha que massa, o Kilderson podia trazer mais tb! Em discussões como essa eu sempre lembro de uma reflexão de que vi numa palestra (não to conseguindo achar qual agora) dizendo Regras simples, em sistemas complexos, geram comportamentos complexos. Um exemplo é a já discutida "entidade não pode ter dependências externas". Uma regra aparentemente simples, mas que aplicada cegamente pode gerar a necessidade de injetar um UUIDGenerator em cada entity - na minha visão deixando o todo mais complexo ao invés de mais simples. E falando em complexidade, deixo aqui mais uma vez um link (já deixei em outro comentário por aqui hehe) para uma playlist do Elemar Jr sobre DDD: ua-cam.com/play/PLkpjQs-GfEMN8CHp7tIQqg6JFowrIX9ve.html Ele já começa jogando na cara como se deve pensar em complexidade de software. É lindo.
Gostaria de acrescentar outro ponto aqui tambem. Em 42:20, onde ele ta "injetando" as dependencias do repository e MailProvider. Seria interessante mostrar isso sendo feito por algum injetor de dependencias próprio, fazendo que com fosse mais simples e direto de modificar as dependencias de um conjunto de Repository por exemplo. Da forma que está, cada repositorio precisa ser injetado manualmente e pode acontecer um erro de o desenvolvedor importar uma implementação de repositorio 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 dependecias resolveria. Seria mais ou menos assim: suponha que você tem 2 implementações possiveis de repositorios, uma para Postregres e outra para MySQL. Aí digamos que os Repository de Postregre estarão na pasta "src/repositories/implementations/postregree" e os de MySQL estão em "implementations/mysql". Usando um injetor de dependencias, bastaria que você mudasse uma configuração (a config que diz qual diretorio de implementações será usado) e aí você rapidamente passaria a usar outro conjunto de repositorios. :)
@@seidenada526 Não é uma questão de preciosismo não, o uncle Bob mesmo fala, se vc quer inserir um código de terceiro deve fazer sua abstração e fazer inversão de dependencia, você assumir que algo é estável e n vai se tornar obsoleto é um erro grave, dependendo do tipo de decisão isso pode virar um cancer no seu sistema(assim como os ORM's haha). Sobre a geração de id acho mais adequado fazer essa injeção dentro do useCase.
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!
Muito interessante e bem apresentado, gostei desse jeito mais rápido de explicar, assim é mais fácil absorver conhecimento e não dá sono. Gostaria sim de ver mais videos sobre arquitetura.
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.
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!
video top Diego, seria muito legal se continua-ses a falar sobre a arquitectura por exemplo eu queria muito ver a implementação em um banco real, e seria muito maneiro fazer um video falando dessa tua personalização legal do teu ubuntu
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!
Parabéns Diego, muito bom o vídeo. Demonstra um exemplo prático de como utilizar esses princípios e ainda facilita quem está estudando clean architecture. Por favor, considere fazer mais vídeos de arquitetura, precisamos muito disso no desenvolvimento, os desenvolvedores não percebem a importância disso para a manutenção de projetos de longo prazo.
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.
Concordo plenamente, na minha visão ele errou feio falando sobre o open/closed principle, a classe tem que estar aberta para extensão e fechada para modificação, modificar um comportamento sobrescrevendo um método de classe é uma coisa muito natural de acontecer e não altera a classe original, só traz novos comportamentos para uma classe que por exemplo implementa o principio de segregação de interfaces.
Show! Já q foi mostrado muita arquitetura e design de sw, não seria bacana uma segundo vídeo estilo step2step demonstrando/explicando camadas de infra.. damoninios desta aplicação? objetivando apresentar a visão do arquiteto modelando antes da implementação. abçs!
Fala Diego! Conteúdo sensacional como sempre. Cara, mesmo você comentando que as vezes é muito complicado aplicar princípios do SOLID no front eu gostaria muito de saber mais como você organiza seus arquivos com React. Hoje minha maior dificuldade é conseguir separar as regras de negócio da aplicação e realizar testes em componentes mais elaborados. Eu acredito que conseguindo fazer a separação os testes sejam mais fáceis, mas de toda forma adoraria ver algum conteúdo sobre isso! Abraço!
Se quiser se aprofundar nesses princípios pro frontend, o Rodrigo Manguinhos, vídeo indicado pelo Elder ali, ele explica muito bem esse cenário. Curso muito bom na Udemy dele, vale demais o investimento.
@@eldervivot Cara, que sensacional! dei uma olhada por alto e curti demais o conteúdo, parece atacar exatamente o meu problema. Muito obrigado pela indicação valiosíssima
Seis são fera de mais, isso pq estava lendo e tentando entender através do Notion de vocês, agora me lança um vídeo mastigadinho, vcs são fodas! Agora uma duvida! Você falou referente ao MVC, ele morreu? É recomendado continuar usando ele? Tem algum substituto melhor? Se sim qual? Vlw pela atenção ai!! #pr #pullrequest #meresponde #tuefoda
Boa, Diego! Eu so tiraria a dependencia do UUID de dentro da entidade User e deixaria na camada de Usecase. Alem disso eu faria tb um interface para o gerador de id. Ate pq eh normal o cliente pedir um id auto-incremento, ou um ID baseado no ano + um codigo.
Eu venho usando uma arquitetura muito similar a tua por algum tempo e vem resultando muito bem. Tenho usado o Nestjs que me auxilia bastante na injeção das dependências e validação dos DTOs. Super recomendo!
Estou tentando fazer este lá no nest também... na hora de fazer tipo o index.ts que ele passa as implementações. a minha implementação da persistencia, que já tem uma injeção de dependencia, reclama que precisa receber 1 argumento, mas não esta recebendo nenhum... e dai jogar a injeção do typeorm lá eu não consegui, como tu fez?
Contraaaats man!! Really good job, really good explanation. Is not easy explain it. I'll appreciate a lot if you give us more videos about this topics, SOLID with more examples, for example add "Post" endpoint to this project (To do it like a blog), DDD, CQRS... I love it! THANK YOU VERY MUUUUCH!! ⭐️⭐️⭐️⭐️⭐️
Eu tava esperando por esse video, acho arquitetura a parte mais principal de um desenvolvimento de projeto perfeito. Apoio trazer mais vídeos sobre o assunto.
Fala Diego! Parabéns pelo vídeo. Gosto bastante desse tipo de vídeo e gostaria de poder ver mais. Como citado em um dos comentários, algumas coisas ficaram “misturadas”, mas acho válido insistir no assunto. Como, por exemplo, como ficariam os testes, as exceções, etc.
Fala Fabiano! Obrigado pelo feedback! Sobre ficarem um pouco misturado é normal. Depois que você aprende ambos, eles fazem tanto sentido juntos que fica difícil separar claramente cada conceito. Mas pode ficar tranquilo que traremos mais vídeos sobre o assunto 💜
Muito obrigado pelo vídeo, agregou muito em meu aprendizado. Se puder trazer mais vídeos sobre arquitetura, patterns e assuntos relacionados, ficarei grato.
Conteúdo muito show! Realmente é algo que sinto falta nos vídeos da Rocketseat, temas mais voltados para arquitetura. São assuntos de abordagem mais complicada mas que com toda certeza fazem a diferença na trajetória de aprendizado de qualquer desenvolvedor. Parabens pelo conteudo!
traz mais videos assim, ajuda muito pessoas iniciantes como eu muitas vezes ficamos inseguros com o código que estamos criando e dá até um receio em mandar ele pro github ou algo assim, e quando vemos esse vídeo percebemos que realmente não estávamos codando da melhor forma, mas aí passamos a ser melhores o que importa é a evolução e esses vídeos ajudam muito nisso
Fala Rocket, conteúdo excelente! Por favor, traga sim mais conteúdo sobre padrões de projeto e arquitetura de software porque são coisas que podem ser reaproveitadas e não tratam só de código mas de mindset mesmo e isso é muito bom!
Cara que show, sabe que para quer iniciar sua carreira solo e não conviveu com a arquitetura tem dificuldade em criar uma aplicação destes moldes. Bom demais apreender com vocês, trás mais desses conteúdos pra nós e de preferência com prisma 2, já esperando mais conteúdos, abs...
Que aula incrível, vou ter que assistir de novo porque tem bastante conteúdo, mas contem muitos conceitos que estou vendo na faculdade, que nesse vídeo sim eu entendi boa parte dos conceitos de baixo acoplamento, em organizar parte dos códigos por pastas e etc, muito bom mesmo!
Boa! Seria muito bom mais vídeos como esse, mostrando a organização das pastas e arquivos principalmente em um projeto maior, e claro, aplicando estes conceitos. Abraço!
Sem dúvida o video mais valioso da Rocket, parabéns! Poste mais sobre arquitetura e padrões, gostaria de aplicar isso no Angular e no React também!!! Ótimo 👍
Perfeito! Gostaria de uma aula dessa com uma implementação de clean arquiteture. Fiquei na dúvida se SOLID se aplica ao fontend também, pq geralmente ele é abordado nas explicações para o backend, assim como o clean arquiteture...
Esse conteúdo é muito importante e gostaria de ver mais por aqui!! Uma dúvida que sempre tive é: de quem é a responsabilidade de fazer validações de campos (verificar se é um e-mail válido, CPF válido, etc)? Do controller? Do useCase?
Muito legal! E com um exemplo bem real. Acho que faltou uma coisa bem importante: Mostrar como é mais fácil fazer a manutenção. Criar um novo repositório e trocar só na injeção, por exemplo. E o entendimento que é mais complicado FAZER e muito mais fácil MANTER esse entendimento faz total diferença na escolha da adoção e quando usar arquiteturas mais "demoradas pra implementar" Vou manter/evoluir esse software por muito tempo? é core da empresa ? ou vai ficar no ar só 1 mês e não terá updates ?
Parabéns, Diego e todo o time da Rocketseat! Seus vídeos são incríveis e me ajudam muito! Deem like no vídeo e compartilhem pessoal. Isso é o mínimo que podemos fazer para retribuir o esforço de produzir conteúdo gratuito e completo como esse. Valeu!
Que conteúdo sensacional! Muito obrigado Rocketseat, faz tempo que não vejo um código tão bonito e bem estruturado KKKKKKK Continuem por favor postando vídeos sobre infraestrutura e boas práticas, vocês são demais!!
Acho muito massa trazerem mais conteúdo sobre arquitetura, acho que é mais difícil encontrar conteúdo sobre. Gostaria de ver também conteúdos de arquitetura pro frontend também.
Angular trabalha assim desde a versão 2, e existe também o NestJs, que é uma implementação em Typescript, usando decorators, pra backend. Sempre preferi, vc pensa mais no início, mas a manutenção nunca mais fica sofrida
Caaaaraca Diego, que arquitetura mind blowing, junto com TypeScript então, casou perfeitamente, to mega empolgado para implementar nos projetos a seguir!! Top demais, você tem a manha!!
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 🚀
Diegão qual ubuntu/linux está usando nesse vídeo?
Faala Luiz! Nesse vídeo é o Ubuntu com KDE 💜
Queria saber qual é esse tema do plasma e da janela de aplicativos com esse tipo de cor, porque eu não acho em lugar nenhum, poderia me ajudar?
Cara, sensacional esses conceitos. Com certeza, estarei aqui para consumir mais conteúdos como esse. Parabéns pela didática.
Conteudo top Diego. Fale um pouco mais sobre Clean Architecture
Sim! Seriam interessantes videos sobre CQRS, DDD e Clean Architecture com node e typescript
concordo!
Sim, demais!!
Up!
amigo, posso sugerir o canal do eximia co, ele aborda esses conceitos, apesar de usar c# os conceitos são bons ...eu tenho aprendido muito com o Elemar jr
Up
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!
Fala Rodrigo! Muito obrigado pelo feedback!! Traremos ainda mais conteúdos agora sobre isso! 💜
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
HAHAHAHA rolou até mensagem subliminar
Kkkkk palmeiras não tem mundial
Palmeiras n tem mundial hu3u3u3
Palmeiras não tem mundial... #true... kkkkkkkkkk
HAHAHAHHAHAHAH Boa!
Esse é com certeza um dos melhores conteúdos sobre SOLID que tem no UA-cam. Obrigado Diego por compartilhar com a gente esse conhecimento. Abraços!
O conteudo que eu mais queria ver aqui! Muito obrigada mesmo, vcs sao incriveis
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!
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!
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 "src/repositories/implementations/postregree" 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,. :)
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 =)
Fala Kilderson, eu também tive alguns "alarmes" soando em relação a algumas colocações do Diego, mas as suas também merecem cuidado!
Primeiramente, minha principal crítica ao apresentado pelo Diego é sobre quando ele disse que "SOLID não dá para aplicar no front, onde temos que seguir mais as decisões do framework" - acho bem errada a colocação hahah
Os princípios não dizem em nada que só se aplicam a back-end. Basicamente ele usou algumas libs (express, mail, db) e separarou a lógica de negócio desses periféricos. Isso é bem possível de se fazer no front, mas acho que pra maioria das pessoas falta um "guia" de como fazer. No back temos as receitas de bolo controller+repository+model+services que já engessam, ou ajudam, as pessoas a pensar em desacoplamento, enquanto no front esses padrões não estão tão estabelecidos.
Sobre a sua crítica a usar um gerador de ID na classe User, eu acho que você está sendo radical e perdendo o sentido num preciosismo. Afinal, qual o limite de "código de terceiro" que não pode estar na camada de domínio? Se eu quiser usar um HashSet da vida no meu modelo, vou ter que importar essa classe. É um código de terceiro também. Então se javascript tivesse um uuid generator "nativo" ele poderia ter usado diretamente? A linha é sutil né.
Eu acho que o seu ponto é na verdade para termos cuidado com código terceiro pois ele pode mudar facilmente ou ainda oferecer uma api que traga complexidade desnecessária para o domínio. Agora, se ele confia que a uuidv4 é uma lib estável e vai apenas usar 1 função dela, é mais simples apenas usá-la como ele fez. Criar mais uma IUUIDGenerator e uma implementação concreta que chama a lib para apenas 1 método e depois ter que ficar injetando isso sempre que se criar uma entity vai deixar o código mais complexo e mais difícil de se trabalhar!
E sobre gerar o ID no repository: tem casos mais complexos, por exemplo quando se deseja criar entidades relacionadas (manja aggregates?) que vão exigir algumas idas e vindas ao repositório desnecessárias. Posso bolar um exemplo caso esteja interessado.
É isso. Valeu por trazer a discussão e valeu mais ainda ao pessoal da Rocket pelo conteúdo de alta qualidade!
@@seidenada526 Por favor, continuem a discussão que eu tô aprendendo à balde! Hahaha!
@@viniciusneto6824 Hahaha que massa, o Kilderson podia trazer mais tb!
Em discussões como essa eu sempre lembro de uma reflexão de que vi numa palestra (não to conseguindo achar qual agora) dizendo Regras simples, em sistemas complexos, geram comportamentos complexos. Um exemplo é a já discutida "entidade não pode ter dependências externas". Uma regra aparentemente simples, mas que aplicada cegamente pode gerar a necessidade de injetar um UUIDGenerator em cada entity - na minha visão deixando o todo mais complexo ao invés de mais simples.
E falando em complexidade, deixo aqui mais uma vez um link (já deixei em outro comentário por aqui hehe) para uma playlist do Elemar Jr sobre DDD: ua-cam.com/play/PLkpjQs-GfEMN8CHp7tIQqg6JFowrIX9ve.html Ele já começa jogando na cara como se deve pensar em complexidade de software. É lindo.
Gostaria de acrescentar outro ponto aqui tambem. Em 42:20, onde ele ta "injetando" as dependencias do repository e MailProvider. Seria interessante mostrar isso sendo feito por algum injetor de dependencias próprio, fazendo que com fosse mais simples e direto de modificar as dependencias de um conjunto de Repository por exemplo. Da forma que está, cada repositorio precisa ser injetado manualmente e pode acontecer um erro de o desenvolvedor importar uma implementação de repositorio 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 dependecias resolveria. Seria mais ou menos assim: suponha que você tem 2 implementações possiveis de repositorios, uma para Postregres e outra para MySQL. Aí digamos que os Repository de Postregre estarão na pasta "src/repositories/implementations/postregree" e os de MySQL estão em "implementations/mysql". Usando um injetor de dependencias, bastaria que você mudasse uma configuração (a config que diz qual diretorio de implementações será usado) e aí você rapidamente passaria a usar outro conjunto de repositorios. :)
@@seidenada526 Não é uma questão de preciosismo não, o uncle Bob mesmo fala, se vc quer inserir um código de terceiro deve fazer sua abstração e fazer inversão de dependencia, você assumir que algo é estável e n vai se tornar obsoleto é um erro grave, dependendo do tipo de decisão isso pode virar um cancer no seu sistema(assim como os ORM's haha). Sobre a geração de id acho mais adequado fazer essa injeção dentro do useCase.
Sensacional! Bem explicado, direto e simples.
Faça mais vídeos de arquitetura, por favor! Eles são incríveis!
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!
Faaala Daniel! Valeeeu pelo feedback! 💜
O conteúdo técnico desse vídeo é sensacional!
Já subi de level só com esse vídeo aí. Valeu de mais galera
Excelente conteúdo. Muito top, aprendendo muito.
Que show que ta curtindo, João! 💜 🚀
Muito interessante e bem apresentado, gostei desse jeito mais rápido de explicar, assim é mais fácil absorver conhecimento e não dá sono. Gostaria sim de ver mais videos sobre arquitetura.
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.
Hahaha que massa Moacir! Valeeu pelo feedback ! 💜
Ficou muito bom, obrigado por compartilhar seu conhecimento.
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!
Hahahaha valeeu pelo feedback Rafael!! 💜
video top Diego, seria muito legal se continua-ses a falar sobre a arquitectura por exemplo eu queria muito ver a implementação em um banco real, e seria muito maneiro fazer um video falando dessa tua personalização legal do teu ubuntu
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!
Parabéns Diego, muito bom o vídeo. Demonstra um exemplo prático de como utilizar esses princípios e ainda facilita quem está estudando clean architecture.
Por favor, considere fazer mais vídeos de arquitetura, precisamos muito disso no desenvolvimento, os desenvolvedores não percebem a importância disso para a manutenção de projetos de longo prazo.
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.
Concordo plenamente, na minha visão ele errou feio falando sobre o open/closed principle, a classe tem que estar aberta para extensão e fechada para modificação, modificar um comportamento sobrescrevendo um método de classe é uma coisa muito natural de acontecer e não altera a classe original, só traz novos comportamentos para uma classe que por exemplo implementa o principio de segregação de interfaces.
Concordo 100% com a sua consideração. Inclusive, se procurar exemplos simples por aí, todos vão de encontro com o que você disse.
Show!
Já q foi mostrado muita arquitetura e design de sw, não seria bacana uma segundo vídeo estilo step2step demonstrando/explicando camadas de infra.. damoninios desta aplicação? objetivando apresentar a visão do arquiteto modelando antes da implementação.
abçs!
Fala Diego! Conteúdo sensacional como sempre. Cara, mesmo você comentando que as vezes é muito complicado aplicar princípios do SOLID no front eu gostaria muito de saber mais como você organiza seus arquivos com React. Hoje minha maior dificuldade é conseguir separar as regras de negócio da aplicação e realizar testes em componentes mais elaborados. Eu acredito que conseguindo fazer a separação os testes sejam mais fáceis, mas de toda forma adoraria ver algum conteúdo sobre isso!
Abraço!
Dê uma olhada neste vídeo ua-cam.com/video/iUQVZHzqGuc/v-deo.html , ele aborda um pouquinho de SOLID no front com React, é fera também como o Diego.
Eu tenho procurado fazer a separação no Frontend também, separando principalmente os usecases. Pode me procurar se quiser
Se quiser se aprofundar nesses princípios pro frontend, o Rodrigo Manguinhos, vídeo indicado pelo Elder ali, ele explica muito bem esse cenário. Curso muito bom na Udemy dele, vale demais o investimento.
Ele também tem outros vídeos no canal sobre arquitetura e padrões de projeto, muito bons. Além dos da Udemy citado acima.
@@eldervivot Cara, que sensacional! dei uma olhada por alto e curti demais o conteúdo, parece atacar exatamente o meu problema. Muito obrigado pela indicação valiosíssima
Seis são fera de mais, isso pq estava lendo e tentando entender através do Notion de vocês, agora me lança um vídeo mastigadinho, vcs são fodas!
Agora uma duvida! Você falou referente ao MVC, ele morreu? É recomendado continuar usando ele? Tem algum substituto melhor? Se sim qual? Vlw pela atenção ai!!
#pr #pullrequest #meresponde #tuefoda
arquitetura e sensacional, quanto mais video tiver sobre o assunto melhor, video excelente!!!!!!!
ADOREI.....seria ótimo a sequência: SOLID + Clean Architecture + TDD com Typescript, NodeJS e Fastfy (no lugar do Express)..pedi muito? rsrs
Observei que agora você está olhando para os princípios de arquitetura. Massa de mais.
É Diego, vendo esses vídeos fica mais a vontade de comprar um bootcamp de vocês.
Mesmo o vídeo sendo antigo, parabéns!
Diego achei fantástico o conteúdo.. Já vou correndo aplicar nos meus projetos. Espero mais conteúdos como esse. Vlw!
Boa, Diego! Eu so tiraria a dependencia do UUID de dentro da entidade User e deixaria na camada de Usecase. Alem disso eu faria tb um interface para o gerador de id. Ate pq eh normal o cliente pedir um id auto-incremento, ou um ID baseado no ano + um codigo.
fala, Diego. mto massa ver esse video c SOLID. parabens. gostaria de ver mais videos sobre CQRS, DDD e Clean Architecture com node e typescript.
Valeu Diego. Conteúdo incrível.
Diego, Rocketseat. Muito Obrigado!!! Esse vídeo em especial é de uma qualidade de conhecimento fora do comum. Sensacional!!!!!
Gostei da estrutura da aplicação.
Eu venho usando uma arquitetura muito similar a tua por algum tempo e vem resultando muito bem. Tenho usado o Nestjs que me auxilia bastante na injeção das dependências e validação dos DTOs. Super recomendo!
Valeeu por compartilhar com a gente sua experiência e opinião! 💜💜
Estou tentando fazer este lá no nest também... na hora de fazer tipo o index.ts que ele passa as implementações. a minha implementação da persistencia, que já tem uma injeção de dependencia, reclama que precisa receber 1 argumento, mas não esta recebendo nenhum... e dai jogar a injeção do typeorm lá eu não consegui, como tu fez?
Contraaaats man!!
Really good job, really good explanation. Is not easy explain it.
I'll appreciate a lot if you give us more videos about this topics, SOLID with more examples, for example add "Post" endpoint to this project (To do it like a blog), DDD, CQRS... I love it!
THANK YOU VERY MUUUUCH!!
⭐️⭐️⭐️⭐️⭐️
Fantástico! Isso era exatamente o que faltava para ser ensinado. Parece que a Rocketseat lê mentes.
Dizem por aí que lemos mesmo 🔮
Gosto desse tipo de conteúdo, TRAGA MAIS!!
Faaaala, William!! Opaaa, TRAREMOS MAIS!! 💜 😛
Por favor mais videos como esse!!!
Simples, claro e prático. obrigado pelo bom trabalho !
Eu tava esperando por esse video, acho arquitetura a parte mais principal de um desenvolvimento de projeto perfeito.
Apoio trazer mais vídeos sobre o assunto.
Faala Everton! Obrigadoo pelo feedback! 💜
Incrível conteúdo Diego!!! Faz mais, faz mais!!
Fala Diego! Parabéns pelo vídeo. Gosto bastante desse tipo de vídeo e gostaria de poder ver mais. Como citado em um dos comentários, algumas coisas ficaram “misturadas”, mas acho válido insistir no assunto. Como, por exemplo, como ficariam os testes, as exceções, etc.
Fala Fabiano! Obrigado pelo feedback! Sobre ficarem um pouco misturado é normal. Depois que você aprende ambos, eles fazem tanto sentido juntos que fica difícil separar claramente cada conceito. Mas pode ficar tranquilo que traremos mais vídeos sobre o assunto 💜
Adoro arquitetura. Por favor faça mais!
Valeeeu Mister! Traremos mais sim!! 💜
Grato pelo conteúdo Diego! Fortaleceu grandão...
Muito obrigado pelo vídeo, agregou muito em meu aprendizado.
Se puder trazer mais vídeos sobre arquitetura, patterns e assuntos relacionados, ficarei grato.
Muita qualidade nesse vídeo, muito conceito envolvido e a aplicação destes em código deixa tudo mais claro. Muito bom!
Por favor continuem falando sobre arquiteturas! Adoraria um video sobre DDD
Conteúdo muito show! Realmente é algo que sinto falta nos vídeos da Rocketseat, temas mais voltados para arquitetura. São assuntos de abordagem mais complicada mas que com toda certeza fazem a diferença na trajetória de aprendizado de qualquer desenvolvedor. Parabens pelo conteudo!
Se falasse uma vez por semana sobre arquitetura seria perfeito, pode ser vídeo longo que dá nada, o importante é aprender.
Opa! Vamos trazer mais conteúdo sobre arquitetura sim Jefferson! 💜💜
Fala Diego! Excelente video, por favor se possível crie mais conteúdo relacionado a arquitetura sim ! valeeu
Faala Thales! Com certeza traremos mais sim!! 🚀💜
Top! Quem sabe um vídeo sobre design patterns ein @Rocketseat?
traz mais videos assim, ajuda muito pessoas iniciantes como eu
muitas vezes ficamos inseguros com o código que estamos criando e dá até um receio em mandar ele pro github ou algo assim, e quando vemos esse vídeo percebemos que realmente não estávamos codando da melhor forma, mas aí passamos a ser melhores
o que importa é a evolução e esses vídeos ajudam muito nisso
Isso ai Emilio! Ficamos felizes que tenha curtido. Com certeza traremos outros vídeos semelhantes!! 💜🚀
@@rocketseat opa valeu! 🚀💜
Fala Rocket, conteúdo excelente! Por favor, traga sim mais conteúdo sobre padrões de projeto e arquitetura de software porque são coisas que podem ser reaproveitadas e não tratam só de código mas de mindset mesmo e isso é muito bom!
Que massa que curtiu Kenedy!! Vamos trazer mais, com certeza! Valeeu pelo feedback! 😍
Gostei demais e estou precisando ver mais conteúdos assim para que eu possa tomar melhores decisões e aumentar a minha conciência analítica.
Cara que show, sabe que para quer iniciar sua carreira solo e não conviveu com a arquitetura tem dificuldade em criar uma aplicação destes moldes. Bom demais apreender com vocês, trás mais desses conteúdos pra nós e de preferência com prisma 2, já esperando mais conteúdos, abs...
Já estava utilizando esse formato de projeto mas sem muita teoria que é importante também sempre bom aprender mais.
Que aula incrível, vou ter que assistir de novo porque tem bastante conteúdo, mas contem muitos conceitos que estou vendo na faculdade, que nesse vídeo sim eu entendi boa parte dos conceitos de baixo acoplamento, em organizar parte dos códigos por pastas e etc, muito bom mesmo!
Caramba! Diego é muito diferenciado... tenho que assistir em 0.75x pra poder captar e processar.
Boa! Seria muito bom mais vídeos como esse, mostrando a organização das pastas e arquivos principalmente em um projeto maior, e claro, aplicando estes conceitos. Abraço!
Faaaaala, Gabriel! Opa, ótimo ponto! Sugestão super anotada aqui! 💜
Com certeza fale mais sobre arquitetura. É um assunto importante demais, e a gente vê pouca gente falando de uma maneira boa sobre eles.
Sem dúvida o video mais valioso da Rocket, parabéns! Poste mais sobre arquitetura e padrões, gostaria de aplicar isso no Angular e no React também!!! Ótimo 👍
Fala Leo! Obrigado pelo feedback! Vamos trazer mais vídeos sobre arquitetura e patterns sim! 💜
Muito bom a introdução sobre o SOLID! Por mais papos sobre arquitetura de software!!!
Muito bom o conteudo, legal ver na pratica os conceitos do Solid
Que massa que curtiu, Gustavo! 💜 🚀
Parabéns pelo vídeo, excelente didática na explicação.
Perfeito! Gostaria de uma aula dessa com uma implementação de clean arquiteture. Fiquei na dúvida se SOLID se aplica ao fontend também, pq geralmente ele é abordado nas explicações para o backend, assim como o clean arquiteture...
POR FAVOR CONTINUEMMM
CONTINUAREMOOOS! Hahahah 💜💜
Excelente vídeo, parabéns !
SHOOOOOOOOOW, gostaria de saber mais sobre os testes que vc chegou a citar no vídeo
Conteúdo top. Necessário para sair da superfície. Parabéns
Concerteza!! Traga sempre mais conteúdos sobre clean architecture e clean code. Por favor.
Faala Sandrak! Com certeza traremos!! 💜💜
Saudades dos vídeos de arquitetura no canal, esse já faz um bom tempo
Faala, Leandro! Fica de olho nos próximos então que logo vem 😍🚀
Eu estudo bastante sobre Engenharia de Software e é muito legal ver um conteúdo desse nível explicado com explicado com essa didática
Cara, que aula, adorei o v vídeo e com certeza gostaria de ver mais sobre esse conteúdo
Fala Wesley!! Valeeu pelo feedback ! 💜
diego eh sensacional, mesmo sendo rapido, eu assisti essa aula igual o ep de uma serie, bom demais
Fala, Alexandre! Valeeeeu pelo feedback! 💜
Esse conteúdo é muito importante e gostaria de ver mais por aqui!! Uma dúvida que sempre tive é: de quem é a responsabilidade de fazer validações de campos (verificar se é um e-mail válido, CPF válido, etc)? Do controller? Do useCase?
Faaala, Victor!! Dá uma conferida no episódio de hoje do PR!!! Respondemos sua dúvida por lá! 💜💜
ua-cam.com/video/EXpct54Vc5A/v-deo.html&t=664
@@rocketseat Valeu de mais!!
Espero que venham mais vídeos sobre arquitetura! Ficou show esse.
Muito legal! E com um exemplo bem real. Acho que faltou uma coisa bem importante: Mostrar como é mais fácil fazer a manutenção. Criar um novo repositório e trocar só na injeção, por exemplo. E o entendimento que é mais complicado FAZER e muito mais fácil MANTER
esse entendimento faz total diferença na escolha da adoção e quando usar arquiteturas mais "demoradas pra implementar"
Vou manter/evoluir esse software por muito tempo? é core da empresa ?
ou vai ficar no ar só 1 mês e não terá updates ?
Massa demais esses Code/Drops da Rocketseat
Faaaaaala, Abner! Pessoal mandou bem demais, né? Que show que curtiu! 💜 🚀
Parabéns, Diego e todo o time da Rocketseat! Seus vídeos são incríveis e me ajudam muito! Deem like no vídeo e compartilhem pessoal. Isso é o mínimo que podemos fazer para retribuir o esforço de produzir conteúdo gratuito e completo como esse. Valeu!
Mandou bemzasso no conteúdo!!!! Valeria a pena ver um CRUD finalizado até pra entender o que reutilizar, estrutura de pastas e afins!!! Valeu
Ótimo vídeo. Me senti na minha época de programador Java com Spring + Hibernate. Injeção de dependência, DTO, repositórios, interfaces, etc etc
Hahaha é muito parecido mesmo! 💜
Que conteúdo sensacional! Muito obrigado Rocketseat, faz tempo que não vejo um código tão bonito e bem estruturado KKKKKKK Continuem por favor postando vídeos sobre infraestrutura e boas práticas, vocês são demais!!
Esse tipo de conteúdo é muito top. Acho que leva o desenvolvimento pra um outro nível.
Por favor, traz mais vídeos desse tipo sim!
Acho muito massa trazerem mais conteúdo sobre arquitetura, acho que é mais difícil encontrar conteúdo sobre. Gostaria de ver também conteúdos de arquitetura pro frontend também.
Seria legal ter mais conteúdo sobre esses assuntos. Parabéns!
Falaaa, Hugo! Sugestão anotada! Valeeu! 💜 😍
Angular trabalha assim desde a versão 2, e existe também o NestJs, que é uma implementação em Typescript, usando decorators, pra backend. Sempre preferi, vc pensa mais no início, mas a manutenção nunca mais fica sofrida
Parabéns pelo excelente conteúdo. Gostaria de ver um exemplo das regras de negócio na entidades assim como sugere a arquitetura limpa.
Com certeza quero mais conteúdo assim!!!
Caaaaraca Diego, que arquitetura mind blowing, junto com TypeScript então, casou perfeitamente, to mega empolgado para implementar nos projetos a seguir!! Top demais, você tem a manha!!
Faala, Mateus! Valeeeu pelo feedback! 💜💜
Top d+. Pdia falar mais sobre TDD e BDD e como fazer isso com banco de dados
Top, por mais conteúdo deste assunto.
Obrigado pelo excelente conteúdo, e sim mais vídeos sobre arquitetura
Muito top! Parabéns pelo conteúdo. Sempre interessante e ajudando a comunidade.
Faala Daniel! Obrigado pelo feedback!! 💜💜
cara seu video pode durar o dia todo que assistiria, isso é quase uma faculdade!
Gostei demais do tema sobre arquitetura, faça mais videos por favor.
Sua velocidade que é dificil de acompanhar , mas isso é de boa
Hahahah que show Valdinei! Vamos trazer mais conteúdos sim!! 💜
Mais vídeos sobre arquitetura e tudo que tu disse que poderia falar. Pode trazer vídeos longos.
Assunto show! Adoro consumir conteúdo sobre arquitetura de software