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 🚀
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!
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
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!
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: ruclips.net/p/PLkpjQs-GfEMN8CHp7tIQqg6JFowrIX9ve 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!
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,. :)
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!
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!
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.
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!
3 года назад
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.
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.
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
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.
Incrível ver como esse meu xará não importa o tempo, ele sempre tá a frente na hora de ensinar a codar com qualidade e produtividade! mano, @dieegosf apenas PARABÉNS E OBRIGADO!!! 🎉🙏
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?
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...
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!
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!
Muito obrigado pelo vídeo, agregou muito em meu aprendizado. Se puder trazer mais vídeos sobre arquitetura, patterns e assuntos relacionados, ficarei grato.
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!!
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!!
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 💜
Ah, Diegão, eu curto esses tipos de conteúdos sim. Já tinha um tempo que tinha colocado aqui para "assistir depois", mas agora dei uma parada para ver até porque pode me ajudar muito em uma entrevista que vou ter em breve.
Eu ainda uso o MVC, ele é moderno e não precisa criar um método com mais de uma funcionalidade. O modo como eu faço em PHP é criar classes responsáveis por cada coisa onde cada método faz só uma etapa do que é necessário pra tarefa principal e chamo essa classe no controller.
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!
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.
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.
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!! ⭐️⭐️⭐️⭐️⭐️
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.
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
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
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! 💜
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
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 RUclips. 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!
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: ruclips.net/p/PLkpjQs-GfEMN8CHp7tIQqg6JFowrIX9ve 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.
Já subi de level só com esse vídeo aí. Valeu de mais galera
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!
Sensacional! Bem explicado, direto e simples.
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,. :)
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!! 💜
Observei que agora você está olhando para os princípios de arquitetura. Massa de mais.
Excelente conteúdo. Muito top, aprendendo muito.
Que show que ta curtindo, João! 💜 🚀
Faça mais vídeos de arquitetura, por favor! Eles são incríveis!
Fantástico! Isso era exatamente o que faltava para ser ensinado. Parece que a Rocketseat lê mentes.
Dizem por aí que lemos mesmo 🔮
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!
Caramba! Diego é muito diferenciado... tenho que assistir em 0.75x pra poder captar e processar.
É Diego, vendo esses vídeos fica mais a vontade de comprar um bootcamp de vocês.
Mesmo o vídeo sendo antigo, parabéns!
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 ! 💜
arquitetura e sensacional, quanto mais video tiver sobre o assunto melhor, video excelente!!!!!!!
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!
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.
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! 💜
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
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.
PORFAVOR DIEGOO TRAZ MAIS CONTEUDO NÃO PARE NUNCA EU ASSISTO TODOS OS VIDEOS DA ROCKETSEAR, NÃO IMPORTA SE TEM 10 MIN ou 2 HORAS
Incrível ver como esse meu xará não importa o tempo, ele sempre tá a frente na hora de ensinar a codar com qualidade e produtividade! mano, @dieegosf apenas PARABÉNS E OBRIGADO!!! 🎉🙏
Gosto desse tipo de conteúdo, TRAGA MAIS!!
Faaaala, William!! Opaaa, TRAREMOS MAIS!! 💜 😛
Incrível conteúdo Diego!!! Faz mais, faz mais!!
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!! 💜
Massa demais esses Code/Drops da Rocketseat
Faaaaaala, Abner! Pessoal mandou bem demais, né? Que show que curtiu! 💜 🚀
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?
Adoro arquitetura. Por favor faça mais!
Valeeeu Mister! Traremos mais sim!! 💜
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!
Diego achei fantástico o conteúdo.. Já vou correndo aplicar nos meus projetos. Espero mais conteúdos como esse. Vlw!
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! 😍
Por favor continuem falando sobre arquiteturas! Adoraria um video sobre DDD
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!! 🚀💜
Ficou muito bom, obrigado por compartilhar seu conhecimento.
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! 💜💜
Diego, Rocketseat. Muito Obrigado!!! Esse vídeo em especial é de uma qualidade de conhecimento fora do comum. Sensacional!!!!!
Simples, claro e prático. obrigado pelo bom trabalho !
Muito bom a introdução sobre o SOLID! Por mais papos sobre arquitetura de software!!!
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...
você pegou todo o DDD do gostack e simplificou!!!
:o
que coisa mais mágica.
Simplificou mas não é escalável como o do gostack;
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.
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
diego eh sensacional, mesmo sendo rapido, eu assisti essa aula igual o ep de uma serie, bom demais
Fala, Alexandre! Valeeeeu pelo feedback! 💜
Valeu Diego. Conteúdo incrível.
Cara, que aula, adorei o v vídeo e com certeza gostaria de ver mais sobre esse conteúdo
Fala Wesley!! Valeeu pelo feedback ! 💜
Muito bom o conteudo, legal ver na pratica os conceitos do Solid
Que massa que curtiu, Gustavo! 💜 🚀
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! 💜
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.
Grato pelo conteúdo Diego! Fortaleceu grandão...
Com certeza fale mais sobre arquitetura. É um assunto importante demais, e a gente vê pouca gente falando de uma maneira boa sobre eles.
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!
Cara, esse vídeo merece uns 100 likes
HAHAHAHA! 🤣
Vaaaaaleu, Luis! 💜 😍
Agora sim, um vídeo #full #sensacional para alegrar esse dia triste.
Mandou bemzasso no conteúdo!!!! Valeria a pena ver um CRUD finalizado até pra entender o que reutilizar, estrutura de pastas e afins!!! Valeu
Muita qualidade nesse vídeo, muito conceito envolvido e a aplicação destes em código deixa tudo mais claro. Muito bom!
Concerteza!! Traga sempre mais conteúdos sobre clean architecture e clean code. Por favor.
Faala Sandrak! Com certeza traremos!! 💜💜
Conteúdo top. Necessário para sair da superfície. Parabéns
Top! Quem sabe um vídeo sobre design patterns ein @Rocketseat?
Muito obrigado pelo vídeo, agregou muito em meu aprendizado.
Se puder trazer mais vídeos sobre arquitetura, patterns e assuntos relacionados, ficarei grato.
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! 💜💜
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!!
Já estava utilizando esse formato de projeto mas sem muita teoria que é importante também sempre bom aprender mais.
Seria legal ter mais conteúdo sobre esses assuntos. Parabéns!
Falaaa, Hugo! Sugestão anotada! Valeeu! 💜 😍
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 💜
Assunto show! Adoro consumir conteúdo sobre arquitetura de software
ADOREI.....seria ótimo a sequência: SOLID + Clean Architecture + TDD com Typescript, NodeJS e Fastfy (no lugar do Express)..pedi muito? rsrs
Espero que venham mais vídeos sobre arquitetura! Ficou show esse.
Ah, Diegão, eu curto esses tipos de conteúdos sim. Já tinha um tempo que tinha colocado aqui para "assistir depois", mas agora dei uma parada para ver até porque pode me ajudar muito em uma entrevista que vou ter em breve.
Que massa Fabio! Com certeza traremos mais conteúdo sobre isso sim! 💜💜
Eu ainda uso o MVC, ele é moderno e não precisa criar um método com mais de uma funcionalidade. O modo como eu faço em PHP é criar classes responsáveis por cada coisa onde cada método faz só uma etapa do que é necessário pra tarefa principal e chamo essa classe no controller.
O bom e velho MVC , se bem aplicado, eu diria que até em aplicações de médio porte, é mais que suficiente. No mais, excelente vídeo.
@@renatonascimento7885 exatamente
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!
Gostei da estrutura da aplicação.
Top d+. Pdia falar mais sobre TDD e BDD e como fazer isso com banco de dados
Show, topzera, parabéns equipe da Rocketseat !!!
Por favor mais videos como esse!!!
Esse tipo de conteúdo é muito top. Acho que leva o desenvolvimento pra um outro nível.
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.
Muito top conteúdo , se tiver eu assisto até o final
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.
Mais vídeos sobre arquitetura e tudo que tu disse que poderia falar. Pode trazer vídeos longos.
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!!
⭐️⭐️⭐️⭐️⭐️
Por favor, mais conteúdo como esses são bem vindo!
Faala Wellington! Com certeza traremos mais sim!! 💜
Rocketseat sempre trazendo conteúdo de qualidade! Eu voto por mais conteúdos desse tipo. Valeu, Diego!
Valeeeeu Drache! Com certeza traremos mais sim! 💜
SHOOOOOOOOOW, gostaria de saber mais sobre os testes que vc chegou a citar no vídeo
Gostei muito do conteúdo e gostaria muito de assistir uma série de videos assim !!!
Ó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! 💜
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.
Muito boa a aula! Poderia também criar um vídeo dando continuidade e mostrando como implementar testes em toda essa estrutura.
Fala Diego! Vamos trazer mais conteúdo sobre isso, possivelmente dando continuidade nesse projeto! 💜💜
Com certeza quero mais conteúdo assim!!!
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!
POR FAVOR CONTINUEMMM
CONTINUAREMOOOS! Hahahah 💜💜
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 ruclips.net/video/iUQVZHzqGuc/видео.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