Minha crítica à disciplina de Arquitetura de Software com Framework Java(PUC)

Recentemente finalizei a disciplina Arquitetura de Software com Framework Java (2025), da minha pós-graduação em Arquitetura de Software Distribuído na PUC Minas.

Resolvi escrever sobre ela porque terminei a disciplina com uma sensação um pouco contraditória.

Por um lado, o conteúdo é organizado, as explicações são claras e os conceitos apresentados são importantes.

Por outro, achei que a disciplina ficou resumida demais para o nível de uma pós-graduação.

O conteúdo é bom, mas muito superficial

Durante a disciplina são apresentados Java, Spring Boot, Spring Data, JPA, HTTP e alguns Design Patterns, como:

• Singleton
• Factory
• Facade
• Decorator

Também são apresentadas coisas como @RestController, @SpringBootApplication, @Column, JpaRepository, findById() e os principais métodos HTTP.

Tudo isso é válido.

O problema é que, em vários momentos, o conteúdo parece mais preocupado em apresentar o conceito do que em discutir o problema que aquele conceito resolve.

E acredito que essa diferença seja muito importante quando estamos falando de arquitetura.

Saber usar não é o mesmo que saber decidir

Por exemplo, aprender que o Factory serve para encapsular a criação de objetos é importante.

Mas eu gostaria muito mais de discutir:

Quando realmente vale a pena utilizar Factory?

Quando ele adiciona complexidade desnecessária?

Quais são as alternativas?

Como isso impacta testabilidade, acoplamento e manutenção?

O mesmo vale para Singleton.

Não basta saber que ele garante uma única instância de uma classe.

Seria interessante discutir estado global, concorrência, ciclo de vida, testabilidade e por que mecanismos de injeção de dependência podem ser uma alternativa muito melhor em determinados cenários.

É nesse ponto que, na minha opinião, uma disciplina deixa de ser apenas sobre programação e começa a entrar realmente em arquitetura de software.

E o Spring?

Spring Boot é um ecossistema enorme.

A disciplina apresenta algumas das principais abstrações do framework, mas senti falta de problemas mais próximos daqueles que encontramos em sistemas reais.

Por exemplo:

• Como lidar com alta concorrência?
• Como projetar uma aplicação para escalar horizontalmente?
• Quando utilizar cache?
• Como tratar falhas temporárias?
• Como trabalhar com timeout e retry?
• Como evitar problemas de N+1 no JPA?
• Como lidar com transações?
• Como observar uma aplicação em produção?
• Como estruturar logs?
• Como implementar rastreamento distribuído?
• Quando utilizar comunicação síncrona ou assíncrona?
• Quando um monólito começa a apresentar problemas arquiteturais?
• Quando não devemos utilizar microsserviços?

Essas são perguntas que considero muito relevantes quando o contexto é Arquitetura de Software Distribuído.

A carga horária também me incomodou

Outro ponto foi a carga horária.

Alguns assuntos importantes são apresentados em aulas muito curtas.

Uma aula de poucos minutos consegue explicar o que é determinado conceito, mas dificilmente consegue explorar:

• implementação;
• alternativas;
• limitações;
• trade-offs;
• problemas reais;
• impacto arquitetural;
• testes;
• performance;
• segurança;
• manutenção.

Na minha opinião, o conteúdo de Java poderia tranquilamente ocupar uma carga horária muito maior.

Algo entre 48 e 80 horas, com mais exercícios e estudos de caso, permitiria uma abordagem muito mais interessante.

Talvez minha percepção também seja influenciada pela experiência profissional

Eu já trabalhei profissionalmente com Java, inclusive com Java 6, quando estava na SysMap e atuava em um projeto para a Natura.

Por isso, alguns dos conceitos apresentados não eram novidades para mim.

Mas acredito que isso também seja um ponto importante.

Uma pós-graduação deveria conseguir atender tanto quem está consolidando os fundamentos quanto quem já possui experiência prática e precisa avançar para discussões mais complexas.

Para quem está começando no ecossistema Java, o conteúdo pode funcionar muito bem.

Para quem já trabalha com backend e arquitetura, senti falta de uma segunda camada de profundidade.

O que eu esperava encontrar?

Gostaria de ter visto mais situações como:

Temos uma API que atende 1.000 requisições por segundo. O banco começou a ser o gargalo. O que fazemos?

Ou:

Temos três serviços que precisam manter consistência de dados. Como projetar essa comunicação?

Ou ainda:

Nosso sistema está ficando grande. Devemos separar em microsserviços ou modularizar o monólito?

Esses problemas não possuem simplesmente uma resposta certa.

E é justamente aí que arquitetura fica interessante.

Você precisa avaliar trade-offs.

Talvez cache resolva.

Talvez não.

Talvez microsserviços sejam necessários.

Talvez sejam apenas complexidade adicional.

Talvez uma fila seja adequada.

Talvez aumente a complexidade operacional sem trazer benefício suficiente.

É esse tipo de raciocínio que eu esperava praticar mais durante a disciplina.

Não considero a disciplina ruim

Essa parte é importante.

Minha crítica não é que a disciplina seja ruim.

As explicações são boas.

Os conceitos são relevantes.

O conteúdo consegue apresentar uma boa base.

Minha crítica é principalmente sobre profundidade e direcionamento.

Para uma disciplina introdutória de Java/Spring, eu consideraria o conteúdo bastante adequado.

Para uma disciplina chamada Arquitetura de Software com Framework Java, dentro de uma pós-graduação em Arquitetura de Software Distribuído, eu esperava mais.

Muito mais discussão sobre decisões arquiteturais e menos foco em simplesmente apresentar funcionalidades do framework.

Minha principal conclusão

Depois de trabalhar com diferentes tecnologias e arquiteturas, cada vez mais acredito que existe uma diferença enorme entre:

“Eu sei utilizar uma tecnologia.”

e

“Eu sei quando utilizar essa tecnologia.”

A primeira pergunta é sobre implementação.

A segunda é sobre engenharia.

E talvez esse seja justamente o ponto que eu gostaria de ter visto mais nessa disciplina.

Não apenas como utilizar Java e Spring, mas como tomar boas decisões arquiteturais utilizando Java e Spring em sistemas reais, distribuídos e sujeitos a escala, falhas e mudanças constantes.

No fim, fica minha crítica — mais como uma sugestão de evolução do que como uma reprovação da disciplina.

A base está lá.

Eu só gostaria que ela fosse muito mais explorada.

E gostaria de saber a opinião de quem já fez essa disciplina ou trabalha com arquitetura:

Vocês também sentem que muitos conteúdos de pós-graduação acabam ensinando mais o “como fazer” do que o “por que fazer”?