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!
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.
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,. :)
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!!! 🎉🙏
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.
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.
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.
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 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!
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...
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!
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?
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
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
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 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!
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.
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!
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.
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 👍
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.
O conteúdo do video é muito bom, na minha opinião você deveria ter focado mas nos princípios do SOLID, ao invés de mostra como que eles se encaixam em arquiteturas como Hexagonal Architecture ou Clean Architecture , para quem ta começando ver já isso tudo misturado fica um pouco confuso, mas obrigado por compartilha esse conhecimento tão importante para quem está começando
O NestJS é ótimo para realizar o desenvolvimento seguindo os princípios do SOLID. Ele fornece uma camada de abstração do Express e é um framework opinativo, embora permita desenvolver como bem entender (como praticamente qualquer outro), sempre facilita a quem segue os padrões de entidades, repositories e classes.
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!
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.
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!! ⭐️⭐️⭐️⭐️⭐️
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
![Lethal Company Music Video 🎵 "Follow The Orders" [VERSION A]](http://i.ytimg.com/vi/QeooZB4Z7RA/mqdefault.jpg)
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! 💜
O conteudo que eu mais queria ver aqui! Muito obrigada mesmo, vcs sao incriveis
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!
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
Faça mais vídeos de arquitetura, por favor! Eles são incríveis!
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,. :)
Sensacional! Bem explicado, direto e simples.
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!!! 🎉🙏
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 ! 💜
O conteúdo técnico desse vídeo é sensacional!
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.
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.
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! 💜
Excelente conteúdo. Muito top, aprendendo muito.
Que show que ta curtindo, João! 💜 🚀
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.
Observei que agora você está olhando para os princípios de arquitetura. Massa de mais.
arquitetura e sensacional, quanto mais video tiver sobre o assunto melhor, video excelente!!!!!!!
Com certeza fale mais sobre arquitetura. É um assunto importante demais, e a gente vê pouca gente falando de uma maneira boa sobre eles.
Já estava utilizando esse formato de projeto mas sem muita teoria que é importante também sempre bom aprender mais.
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! 💜💜
Muito obrigado pelo vídeo, agregou muito em meu aprendizado.
Se puder trazer mais vídeos sobre arquitetura, patterns e assuntos relacionados, ficarei grato.
Simples, claro e prático. obrigado pelo bom trabalho !
Ficou muito bom, obrigado por compartilhar seu conhecimento.
Diego, Rocketseat. Muito Obrigado!!! Esse vídeo em especial é de uma qualidade de conhecimento fora do comum. Sensacional!!!!!
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!
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...
Caramba! Diego é muito diferenciado... tenho que assistir em 0.75x pra poder captar e processar.
Muita qualidade nesse vídeo, muito conceito envolvido e a aplicação destes em código deixa tudo mais claro. Muito bom!
Mandou bemzasso no conteúdo!!!! Valeria a pena ver um CRUD finalizado até pra entender o que reutilizar, estrutura de pastas e afins!!! Valeu
É Diego, vendo esses vídeos fica mais a vontade de comprar um bootcamp de vocês.
Mesmo o vídeo sendo antigo, parabéns!
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!
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?
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! 🚀💜
Diego achei fantástico o conteúdo.. Já vou correndo aplicar nos meus projetos. Espero mais conteúdos como esse. Vlw!
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 videos como esse!!!
Por favor continuem falando sobre arquiteturas! Adoraria um video sobre DDD
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.
Gostei da estrutura da aplicação.
Adoro arquitetura. Por favor faça mais!
Valeeeu Mister! Traremos mais sim!! 💜
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! 😍
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
Ó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! 💜
Gosto desse tipo de conteúdo, TRAGA MAIS!!
Faaaala, William!! Opaaa, TRAREMOS MAIS!! 💜 😛
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.
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!
Esse tipo de conteúdo é muito top. Acho que leva o desenvolvimento pra um outro nível.
diego eh sensacional, mesmo sendo rapido, eu assisti essa aula igual o ep de uma serie, bom demais
Fala, Alexandre! Valeeeeu pelo feedback! 💜
Incrível conteúdo Diego!!! Faz mais, faz mais!!
Muito bom a introdução sobre o SOLID! Por mais papos sobre arquitetura de software!!!
Fantástico! Isso era exatamente o que faltava para ser ensinado. Parece que a Rocketseat lê mentes.
Dizem por aí que lemos mesmo 🔮
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
ADOREI.....seria ótimo a sequência: SOLID + Clean Architecture + TDD com Typescript, NodeJS e Fastfy (no lugar do Express)..pedi muito? rsrs
Concerteza!! Traga sempre mais conteúdos sobre clean architecture e clean code. Por favor.
Faala Sandrak! Com certeza traremos!! 💜💜
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! 💜
Valeu Diego. Conteúdo incrível.
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! 💜
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.
Massa demais esses Code/Drops da Rocketseat
Faaaaaala, Abner! Pessoal mandou bem demais, né? Que show que curtiu! 💜 🚀
Por favor, traz mais vídeos desse tipo sim!
Cara, que aula, adorei o v vídeo e com certeza gostaria de ver mais sobre esse conteúdo
Fala Wesley!! Valeeu pelo feedback ! 💜
Mais vídeos sobre arquitetura e tudo que tu disse que poderia falar. Pode trazer vídeos longos.
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.
Parabéns pelo excelente conteúdo. Gostaria de ver um exemplo das regras de negócio na entidades assim como sugere a arquitetura limpa.
Conteúdo top. Necessário para sair da superfície. Parabéns
Por favor, mais conteúdo como esses são bem vindo!
Faala Wellington! Com certeza traremos mais sim!! 💜
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!! 🚀💜
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;
O conteúdo do video é muito bom, na minha opinião você deveria ter focado mas nos princípios do SOLID, ao invés de mostra como que eles se encaixam em arquiteturas como Hexagonal Architecture ou Clean Architecture , para quem ta começando ver já isso tudo misturado fica um pouco confuso, mas obrigado por compartilha esse conhecimento tão importante para quem está começando
POR FAVOR CONTINUEMMM
CONTINUAREMOOOS! Hahahah 💜💜
Grato pelo conteúdo Diego! Fortaleceu grandão...
SHOOOOOOOOOW, gostaria de saber mais sobre os testes que vc chegou a citar no vídeo
Assunto show! Adoro consumir conteúdo sobre arquitetura de software
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!! 💜
O NestJS é ótimo para realizar o desenvolvimento seguindo os princípios do SOLID. Ele fornece uma camada de abstração do Express e é um framework opinativo, embora permita desenvolver como bem entender (como praticamente qualquer outro), sempre facilita a quem segue os padrões de entidades, repositories e classes.
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!
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! 💜💜
Simplesmente incrível
Por favor, traz mais vídeos sobre arquitetura de software!
Muito bom o conteudo, legal ver na pratica os conceitos do Solid
Que massa que curtiu, Gustavo! 💜 🚀
Obrigado pelo excelente conteúdo, e sim mais vídeos sobre arquitetura
Muito bom, vou começar a usar esse modelo, uso muito Adonis por fornecer facilidade, porem o SOLID se aplica muito melhor para outros casos
Boaa! Valeeu Hugo !💜
Muito legal. O tamanho do vídeo ficou ótimo. Seria muito interessante falar mais sobre Arquitetura.
Espero que venham mais vídeos sobre arquitetura! Ficou show esse.
Seria legal ter mais conteúdo sobre esses assuntos. Parabéns!
Falaaa, Hugo! Sugestão anotada! Valeeu! 💜 😍
Gostei muito do conteúdo e gostaria muito de assistir uma série de videos assim !!!
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!!
⭐️⭐️⭐️⭐️⭐️
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
Top d+. Pdia falar mais sobre TDD e BDD e como fazer isso com banco de dados
Interessante esse princípio 5:47
Com certeza quero mais conteúdo assim!!!
Cara, esse vídeo merece uns 100 likes
HAHAHAHA! 🤣
Vaaaaaleu, Luis! 💜 😍
Excelente vídeo, parabéns !