Essa questão das camadas de aplicação do DDD(application service) e clean architecture(use case) ficou um pouco confuso, você sugere utilizar um ou outro? Ou seria possível um use case chamar um service, parece não fazer sentido pois ambos fazem praticamente a mesma coisa. Pra mim a diferença entre service e use case era: service tem todas as ações relacionadas dentro dele(criar usuário/inativar usuário, etc) enquanto que o use case é específico para cada ação existindo um para criar usuário e outro para inativar usuário. Boa explicação pois realmente existe muita confusão ao misturar as duas técnicas.
A ultima frase não ta correta, DDD ele defini conceitos em outros aspectos na arquitetura e justamente no design, ele não tem nenhum relação com o Clean Arquitecture. Mas por isso que eles são aplicaveis em paralelo.
Desculpe-me, mas fazer esse tipo de comparação é como querer comparar um trator com uma ferrari - cada um se aplica em contextos diferentes. Não se trata de uma queda de braço, mas sim de abordagens. Aliás, Clean Architecture deveria se chamar Clean Design, pois trata de design de software e não da arquitetura de software. Lembrem-se: DDD não é sobre arquitetura, mas sim uma abordagem estratégica e tática para atacar complexidade de software. Um outro ponto delicado, uma entidade pode continuar sendo anêmica mesmo possuindo regras de negócio e comportamento. Um exemplo simples: Vejo muitas entidades com métodos do "AlterarPreco", "AlterarSalario", "AlterarStatus". São métodos que expressam comportamento e regras de negócio, mas deixam de fazer o mais importante: Expressar a lógica de negócio ou o motivo de alteração da entidade. Ora, "AlterarSalario" não expressa lógica alguma - salário pode ser alterado por promoção, por reajuste etc. Por que não nomear esse método como por exemplo "ReajustarSalarioPor Promocao" ou "Pedido.Fechar()" aou invés dos famosos "Pedido.AlterarStatus(StatusPedido.Fechado)"?
A linha que separa Arquitetura e Design é tão tênue que não há uma definição tão clara. Arquitetura é a forma pronta que foi construída por inúmeras pequenas implementações de design, portanto, a casa (arquitetura), é um aglomerado de tijolos (design), organizados e estruturados, seguindo alguma ordem. Clean Arch é uma arquitetura sim. Porém, para se construir uma arquitetura, você tem que trabalhar fortemente no design. Por isso que, quando falamos de Clean Arch, estamos estudando design. Uncle Bob deixa isso bem claro no início do livro. Ele mesmo não considera que há uma distinção entre arquitetura e design. No vídeo é muito bem explicado que, Clean Arch e DDD são conceitos - utilizando uma expressão de teoria das cores - análogos, ou seja, são muito similares e estão extremamente próximos, com apenas algumas diferenças bem pequenas, na verdade, um complementa o outro. Pois, enquanto Clean Arch define a organização das implementações do Design em camadas e princípios, o DDD vem pra entender qual o problema que seu software vai resolver e como aplicar isso no código, usando camadas e regras que se interpolam e complementam as camadas do Clean Arch
Isso acontece pois a grande maioria dos devs não sabe OOP, este tipo de método já indica que é totalmente procedural, entidades anêmicas, duplicação de regra de negócio, programação orientada a IF e todo resto que todo mundo já viu na prática. Acho que a ideia de comparar é em relação a aplicação prática dos conceitos pois muita gente começa a misturar isso dentro do código de fato.
o ruim desse video que so pode curtir uma vez... O MELHOR VIDEO SOBRE DDD Q JA ASSISTI
Indiscutivelmente, o melhor material que já consumi sobre clean arch e DDD. Parabéns e obrigado, Wesley.
Esse canal do Wesley, Luiz e cia é um dos melhores em br para os desenvolvedores se atualizarem e eles possuem poucos likes. Pessoal nao ajuda
absurdo de excelente o conteúdo!!
primeiro video q vejo nessa linha de comparacao. otimo. vlw. parabens
Parabêns pelo conteúdo construtivo deste vídeo. 👍
Perfeita análise mostrando a compatibilidade entre os dois modelos!
Excelente aula, estou desenvolvendo um sistema do zero e vou usar Clean Arch com DDD.
parabéns pelo trabalho, muito esclarecedor!
Percebe-se que, quanto melhor for canal sobre a área, menos like e views ele possui.
Ótima comparação. Parabéns!
Muito bom!
parabéns pela ótimo trabalho!
Show!! Esclareceu legal!! Vlw Wesley!!
Essa questão das camadas de aplicação do DDD(application service) e clean architecture(use case) ficou um pouco confuso, você sugere utilizar um ou outro? Ou seria possível um use case chamar um service, parece não fazer sentido pois ambos fazem praticamente a mesma coisa.
Pra mim a diferença entre service e use case era: service tem todas as ações relacionadas dentro dele(criar usuário/inativar usuário, etc) enquanto que o use case é específico para cada ação existindo um para criar usuário e outro para inativar usuário.
Boa explicação pois realmente existe muita confusão ao misturar as duas técnicas.
Que aula cara, parabéns, esclareceu muitas dúvidas e conceitos que são falados na aula de clean arch com o Branas.
Como assim aula cara? Foi grátis!
@@Douglasfaparanhos substitui a palavra cara por Wesley, cara não foi no sentido de preço.
@@danilomendes9362 O que você disse ficou bem claro, não precisa explicar. Ele que precisa ler mais.
@@desenvolvedor2144 Eu acho que ele tava só zuando com o OP.
Top!
E os Aggregates do DDD?
A ultima frase não ta correta, DDD ele defini conceitos em outros aspectos na arquitetura e justamente no design, ele não tem nenhum relação com o Clean Arquitecture. Mas por isso que eles são aplicaveis em paralelo.
Desculpe-me, mas fazer esse tipo de comparação é como querer comparar um trator com uma ferrari - cada um se aplica em contextos diferentes. Não se trata de uma queda de braço, mas sim de abordagens. Aliás, Clean Architecture deveria se chamar Clean Design, pois trata de design de software e não da arquitetura de software. Lembrem-se: DDD não é sobre arquitetura, mas sim uma abordagem estratégica e tática para atacar complexidade de software. Um outro ponto delicado, uma entidade pode continuar sendo anêmica mesmo possuindo regras de negócio e comportamento. Um exemplo simples: Vejo muitas entidades com métodos do "AlterarPreco", "AlterarSalario", "AlterarStatus". São métodos que expressam comportamento e regras de negócio, mas deixam de fazer o mais importante: Expressar a lógica de negócio ou o motivo de alteração da entidade. Ora, "AlterarSalario" não expressa lógica alguma - salário pode ser alterado por promoção, por reajuste etc. Por que não nomear esse método como por exemplo "ReajustarSalarioPor Promocao" ou "Pedido.Fechar()" aou invés dos famosos "Pedido.AlterarStatus(StatusPedido.Fechado)"?
O que é arquitetura?
A linha que separa Arquitetura e Design é tão tênue que não há uma definição tão clara. Arquitetura é a forma pronta que foi construída por inúmeras pequenas implementações de design, portanto, a casa (arquitetura), é um aglomerado de tijolos (design), organizados e estruturados, seguindo alguma ordem.
Clean Arch é uma arquitetura sim. Porém, para se construir uma arquitetura, você tem que trabalhar fortemente no design. Por isso que, quando falamos de Clean Arch, estamos estudando design. Uncle Bob deixa isso bem claro no início do livro. Ele mesmo não considera que há uma distinção entre arquitetura e design.
No vídeo é muito bem explicado que, Clean Arch e DDD são conceitos - utilizando uma expressão de teoria das cores - análogos, ou seja, são muito similares e estão extremamente próximos, com apenas algumas diferenças bem pequenas, na verdade, um complementa o outro. Pois, enquanto Clean Arch define a organização das implementações do Design em camadas e princípios, o DDD vem pra entender qual o problema que seu software vai resolver e como aplicar isso no código, usando camadas e regras que se interpolam e complementam as camadas do Clean Arch
Isso acontece pois a grande maioria dos devs não sabe OOP, este tipo de método já indica que é totalmente procedural, entidades anêmicas, duplicação de regra de negócio, programação orientada a IF e todo resto que todo mundo já viu na prática.
Acho que a ideia de comparar é em relação a aplicação prática dos conceitos pois muita gente começa a misturar isso dentro do código de fato.