3
benevanio
5 min de leitura ·

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”?

Carregando publicação patrocinada...
2

Vou escrever uma opinião aqui e provavelmente ninguém vai gostar. Mas é a realidade.

Na faculdade, e pós-graducões, raramente utiliza o assunto de estudo. E raramente sabe do que está falando.

Veja que eu disse: raramente. Há exceções com certeza.

Quando fiz a graduação em engenharia elétrica puxei duas matérias da pós graduação de sistemas de controle.

Assunto muito matemático e muito empolgante. Mas servia para quê? Eu pesquisei sobre o assunto e fui para a primeira aula com uma perspextica.

Depois da primeira aula vi que o professor ali não demonstrava domínio do que ele estava falando.

Mas qual a razão disso? Simples: cumprir carga horária e porque ele foi mandado fazer isso. Simples assim. Indaguei o professor várias vezes sobre as aplicações do assunto e depois de muito tempo ele me puxou de lado e disse: eu não domino este assunto. Me foi pedido para dar aula sobre isso e estou aqui dando o meu melhor.

Só validou o que eu já suspeitei desde o primeiro dia. As aulas pareciam que eram basicamente focadas em resolver lista de exercícios sem sentido que não nos levaria a lugar algum. A disciplina era Sistemas de Controle Não-Lineares.

A segunda disciplina da pós-graduação foi totalmente diferente. Era sobre diagnóstico de falahad de motor de indução. E foi ministrada por um professor fenomenal que trabalhou anos na indústria abordando este tema. Porém a aula era focada em problemas práticos.

Quando finalizei a graduação, fui em busca de um mestrado. Depois de 2 anos, larguei. Não fazia mais sentido viver um universo em que de 5 aulas, apenas 1 me mostrava conteúdo real e aplicável.

É triste e fiquei abalado, porque investi horas e horas e horas em produzir artigos. Pesquisas na internet para entender as aplicações dos assuntos e noites viradas com ansiedade, tentando entender se aquilo ali era realmente pra mim.

A verdade é que o sistema de ensino trata os alunos como agentes passivos: eles ouvem a aula, fazem exercícios em casa e vão para a casa ao fim do dia com a falsa perspectiva que estão aprendendo algo.

Quand você promove o aluno a agente ativo da discussão, ele é o protagonista. Mas isso ainda é difícil no Brasil.

Veja, não quero tirar o aluno da posição de buscar o conhecimento após as aulas. Porém é mais importante, e isso é puramente minha opinião, que o tempo de aula seja realmente aproveitado com exemplos, prática e discussão.

1
1

Cara,
Procura uma aplicação para todo esse conhecimento.
Eu fiquei com a impressão de que você no fundo já visualizou algo como 'um caminho a trilhar', 'um desafio', 'uma jornada'
Meu conselho é que se comprometa com o projeto

motivação é algo muito sério, muito importante
tem TUDO a ver com trabalho

E a gente aqui escrevendo código somos as formigas trabalhando para o futuro
você certamente tem habilidade com programação
seu caso específico parece apresentar demanda de administração, empreendedorismo e outras áreas relacionadas

1

Mas faculdade é isso mesmo.

Você não vai aprender na faculdade, mas a faculdade vai te dar uma noção para você saber o que existe e o que você pode estudar.

1

Assim como o Guilherme, achei raso para especialização.
Em POO2 na facul que fiz (UFU), professor mostrava todos os padrãos de projeto do gof (obviamente era algo por cima e se focava em uns 10 paterns mais utilizados), além disso tinha concorrência e multithread, generics do java e mais algumas coisas. Mas por outro lado era considerado na época pela maioria um professor bem exigente. E por ser muito conteúdo dificilmente se dominava estes assuntos, se é quê da pra da pra dominar isso de fato, só o gof ja é uma Bíblia. Lado ruim é que não tinha nada de spring boot, usava-se o temível apache net beans

1
1

Excelente crítica. O próprio nome da disciplina já deixa escapar uma confusão comum: Java é linguagem e plataforma, enquanto Spring, Quarkus ou Micronaut são os frameworks.
O ponto central que você levantou é a dor de quase toda pós-graduação na área: confundem "ensinar sintaxe de framework" com "ensinar arquitetura de software".
Aprender a colocar @RestController, @Column e chamar findById() é tutorial básico de introdução ao ecossistema. Arquitetura de verdade não é sobre decorar anotações do Spring, mas sim sobre entender os trade-offs:
Por que e quando NÃO usar JPA/Hibernate para evitar problemas clássicos de N+1 e consumo de memória em alta escala?
Como desenhar as fronteiras do domínio para que a regra de negócio não fique refém e acoplada ao framework web?
Como a aplicação se comporta sob concorrência real, falhas parciais de rede e gerenciamento de transações?
Sua frase resume perfeitamente: "Saber usar não é o mesmo que saber decidir". Enquanto os cursos focarem em ensinar onde colocar anotações em vez de ensinar a avaliar custos, restrições e consequências de design, continuarão formando operadores de framework em vez de arquitetos de software. Parabéns pela reflexão!