Estou decepcionado com o curso

Oi Gabriel,

Eu particularmente não gosto de seguir padrões apenas pelo fato de que está todo mundo fazendo. Levo pra vida comigo uma frase que minha mãe dizia quando eu era pequeno e queria fazer algo que todo mundo fazia e ela não me deixava: "Você não é todo mundo!".

Nunca gostei de ser um "conformista", aceitando e fazendo as coisas puramente por fazer ou porque os outros sempre fizeram de determinado jeito. Eu sempre gostei de questionar e entender as motivações e benefícios de cada decisão, e seguia apenas se fizesse sentido e fosse comprovado com fatos e evidências e não com opinião.

Um exemplo que me recordo dessa situação: antigamente quando se desenvolvia aplicações cliente-servidor era comum se utilizar os padrões VO(Value Object) e BO(Business Object), para se ter como benefício uma melhor performance/escalabilidade/disponibilidade nas aplicações. Eu sempre achei isso péssimo, pois ia contra os princípios da orientação a objetos, mas entendia os trade-offs dessa decisão. Depois de muitos anos ainda encontrei diversos projetos com esse tipo de padrão sendo utilizado, mesmo em aplicações que não eram distribuídas, o que não fazia o menor sentido. Quando questionava o porquê de tal decisão a resposta era sempre a mesma: "esse é o padrão do mercado. Todo mundo faz assim nos projetos".

Pois é, ainda bem que eu não sou todo mundo e só aplico algo quando faz sentido e comprovadamente vai trazer benefícios :D

Sobre o curso em si, o foco dele é ensinar Spring Boot e não boas práticas de arquitetura e design de código. Justamente por isso o foco foi uma aplicação simples, um CRUD tradicional, e não uma aplicação complexa.

Será que faz sentido criar uma camada a mais na aplicação simples, que vai implicar em mais código para manutenção e consequentemente mais custos, apenas por ser o "padrão do mercado"? Uma das coisas que mais vejo por aí nos projetos são camadas desnecessárias, que apenas delegam para outras camadas, não fazendo o menor sentido. Isso só torna o código mais complexo para entender e dar manutenção(inclusive manutenção e custos são coisas que, infelizmente, quase nenhum dev se preocupa).

Desenvolver software é um trabalho criativo, deveríamos pensar em novas soluções e formas mais simples de resolver problemas, não nos limitando a sempre fazer a mesma coisa, quase como um robô :D

Um exemplo de criatividade foi a classe DTO receber o repository para realizar a conversão de objetos, pois isso evitou a necessidade de se criar uma classe service na aplicação, sem prejudicar em manutenção. Da para fazer testes de unidade nesse dto tranquilamente, além da classe deixar de ser anêmica e passar a ter comportamentos e não apenas atributos.

De qualquer forma agradecemos o feedback. :)

Bons estudos!

Ótima resposta. Muito melhor do que adotar um padrão pelo simples motivo de que é um "padrão de mercado", por melhor que seja, é entender o motivo pelo qual o mercado costuma adotar esse padrão, e tomar uma decisão de se adotar ou não o padrão baseando-se nos prós e contras oferecidos por ele. Afinal, padrões não surgiram do nada, eles têm um motivo para existir, que pode deixar de ser válido com o passar do tempo, como no exemplo do VO/BO.

Mas nesse caso específico eu ainda adotaria a camada de Service, para manter as classes de Resource com a única responsabilidade de fazer a interface entre a Aplicação e clientes REST - seguindo o SRP - Single Responsability Principle. Isso facilitaria trocar ou até adicionar outros modelos de comunicação, como o GraphQL ou outros novos que surgirem.