A classe Usuario não poderia ter esse toEntity. Vc está importando uma classe de infra na camada de domain. O correto seria criar um mapper na camada de infra/adapter
@MatheusdoJava5 ай бұрын
Poxa, fiquei triste agora. Porque gravei esse video duas vezes e na primeira vez que gravei falei que estava criando na usuario só pra otimizar o tempo. Mas que o mais correto seria um mapper em uma outra camada. Porém acabei gravando de novo em cima do vídeo anterior que já estava pronto e que acabou indo com essa questão do entity. Você está corretíssimo e vou fixar esse comentário.
@Guilherme-n4m6z5 ай бұрын
Bom dia amigo! Desculpa incomodar, mas estou em dúvida e se alguém puder ajudar, agradeceria muito! Entendo que na camada de infra ficam as coisas externas a minha aplicação, como utilização de frameworks e serviços externos. Mas em muitos projetos que vejo, colocam dentro do app o service, e lá tem algumas anotações do framework, como @Service, etc. Teria problema? Outra coisa: Nos DTOs que utilizo, faço uso do Bean Validation, apenas validações básicas para cada atributo, como @NotNull, @NotBlank, @Min, etc. Alguns colocam o DTO sem essas validações dentro de domain, outro colocam dentro de infra. O correto mesmo seria ter um DTO com todas essas validações dentro de infra e o dto "limpo" apenas com os atributos dentro de domain? E criar um mapper pra isso? Parecido com o que você sugeriu para a Entity?
@programacaojajava5 ай бұрын
@@Guilherme-n4m6z Minha contribuição: Primeira resposta para sua pergunta é sim, teria problema se você está seguindo pragmaticamente os princícios da clean arch, mas na prática, dia a dia, não vejo tanto problema assim. O problema que poderia dar ao meu ver seria caso você fosse trocar o framework, precisaria fazer uma adaptação nessa parte, ou seja, não seria um copy-paste do seu módulo de application e domain para o outro framework uma vez que vc deixou o framework (um pouco) dentro do domínio. Sobre a segunda pergunta, depende um pouco de onde está esse DTO, se for DTO que vem de fora, chega na infra, pode usar as annotations do BeanValidation. O ponto é que, será que sempre suas entidades/domain serão chamados desses controllers? A ideia é ter o domínio coerente (cada agregate root sabe se validar minimamente) e validações que são mais de negócio (envolvem 1 ou N entidades) vc faz na application layer por exemplo.
@marcusrodrigues719820 күн бұрын
@@programacaojajavapois é acho bom a nível de estudo seguirmos todas as regras do Clean arch, mas convenhamos no dia dia não utilizar anotações do Spring ou um Lombok estaríamos reinventando a roda. Em qual situação chegaríamos no ponto de trocar o framework em que as próprias regras de negócios não precisariam ser revistadas e refatoradas?!! Não precisamos ser tão xiitas.
@programacaojajava16 күн бұрын
@@marcusrodrigues7198 sim, concordo contigo. Eu respondi sobre o que diz a referência, a parta teórica. No mundo real eu acho uma loucura usar isso. Uma coisa ou outra você pode usar como boa prática. Pessoalmente, eu só tentaria isolar coisas mais externas mesmo (api, alguma lib para uma funcionalidade específica), o resto eu deixaria acoplado, inclusive o framework, se um dia eu fosse trocar de framework, eu reescreveria o software mesmo, aproveitando o que desse para aproveitar.
@luisfernandoteixeirademace6882 ай бұрын
Muito boa a explicação sobre Injeção x Inversão
@MatheusdoJava8 ай бұрын
Repositório do projeto: github.com/matheuspieropan/aula-youtube/tree/main/Arquiteturas/Clean Siga o instagram do canal: instagram.com/matheusdojava Aprenda comigo microsservicos com RabbitMQ: www.udemy.com/course/microsservicos-com-spring-e-rabbitmq-aws/?couponCode=8EE4ECD8543C840EA1D8 Se não estiver com desconto me chame nas redes sociais que separo um cupom para você
@Zaratustra_888 ай бұрын
Ótimo seu vídeo, vejo que muitas vagas tem exigido bastante conhecimento de testes unitários e Clean Architecture, o Spring Boot por si só já nos dá muito auxilio em uma arquitetura limpa. Gostaria muito que você fizesse um vídeo explicando sobre padrões de projetos, acho muito massa o padrão builder.
@MatheusdoJava8 ай бұрын
Fala amigo. Pior que já tenho uma playlist de padrão de projeto. Inclusive falo do builder
@ThePowerguide8 ай бұрын
Conteúdo top! Parabéns!
@MatheusdoJava8 ай бұрын
muito obrigado amigo
@MenandroDias6 ай бұрын
Muito legal! Parabéns! Um complemento seria separar em Modulos Maven a aplicação
@giovaneavelinotiburcio98125 ай бұрын
Excelente , obrigado
@geladozx7 ай бұрын
Matheus, ensina o padrao observer com java, vc explica mt bem, to estudando isso na faculdade mas to com dificuldades de entender
@marcusrodrigues719820 күн бұрын
Estou criando um projeto para estudar Clean arquiteture, mas tô enfrentando alguns problemas. Primeiro tive que criar interface dos meus UC, pois precisava injetar uns nos outros. Depois mudei isso para evento, porwm acabei precisando utilizar anotações de ApplicationEvent. Mas na minha infra ainda tenho alguns problemas. Estou consumindo uma API externa, está ficando alguma regra de negócio na parte externa do core ou então tenho que trazer para o meu core está regra porém vai estar altamente acoplada a está API externa.
@GSBNeto8 ай бұрын
Top demais mano
@MatheusdoJava7 ай бұрын
Muito obrigado mano
@eduardoaraujo99888 ай бұрын
Excelente vídeo!
@MatheusdoJava8 ай бұрын
valeu man :D
@albertoborges72468 ай бұрын
Muito bom, mano. Vou dar tentar dar uma brincada com esse tipo de arquitetura tambem. Uma pergunta quando voce diz inversão de dependência, seria aquele princípio IoC(inversion of control)?
@walmircardosodossantosrosa12057 ай бұрын
Sei que a pergunta não foi pra mim , mas e exatamente isso Alberto, de uma olhada depois nos conceitos solid , nesses conceitos eles abordam tanto a inversão de controle quanto também outros topicos.
@isinha667 ай бұрын
você recomenda fazer projeto com a arquiteturas em camadas ou arquitetura limpa?
@MatheusdoJava6 ай бұрын
Fala isinha, tudo bem? Então, pra ser honesto nem sei responder porque sendo honesto, acho legal a ideia da arquitetura limpa. Tanto que fiz esse vídeo. Mas será que nosso projetor realmente pode estar sujeito a nossas implementações para que eu use o príncipio de inversão de controle? Será que realmente posso ter um JpaRepository e ao mesmo tempo um TxtRepository, como citados no vídeo? O problema é que muita empresa implementa ela e o projeto faz a mesma coisa e vai continuar fazendo a mesma coisa. Se conecta apenas com um banco de dados, nao tem nenhum tipo de personalizacao ou coisa do tipo.. nessas casas a arquitetura limpa se faz desnecessária. Agora se eu realmente tenho um projeto que de um lado tenho uma implementacao que trabalha com um banco de dados e do outro lado preciso consumir um arquixo txt, csv e tals.. (como no exemplo do vídeo) a arquitetura limpa vai fazer muito sentido