Recentemente concluí a disciplina Arquitetura de Software com Framework Java (2025), da minha pós-graduação em Arquitetura de Software Distribuído na PUC Minas.
A disciplina aborda temas relevantes: Java, Spring Boot, Spring Data, JPA, HTTP e alguns Design Patterns, como Singleton, Factory, Facade e Decorator.
As explicações são claras e a didática é boa.
Mas, sendo bastante sincero, terminei a disciplina com a sensação de que o conteúdo ficou aquém do que eu esperava de uma especialização em arquitetura de software.
O problema não é o conteúdo. É a profundidade.
Não considero os assuntos escolhidos inadequados. Pelo contrário.
O problema está na forma como eles são explorados.
Em diversos momentos, a abordagem fica muito próxima de uma introdução:
O que é o padrão?
Para que serve?
Como implementar?
Próximo assunto.
Isso funciona muito bem para quem está tendo o primeiro contato com determinado conceito.
Porém, quando estamos falando de arquitetura de software, especialmente em sistemas distribuídos, acredito que a discussão deveria avançar para outro nível.
Não apenas:
“Como utilizar o Factory?”
Mas também:
“Qual problema arquitetural estou tentando resolver com o Factory? Quais são as alternativas? Quais são os trade-offs? O uso desse padrão realmente melhora o design ou estou apenas adicionando complexidade?”
Essa diferença é importante.
Design Patterns não deveriam ser apenas implementações
Durante a disciplina são apresentados padrões como Singleton, Factory, Facade e Decorator.
Conhecer esses padrões é importante.
Mas acredito que uma disciplina de arquitetura deveria explorar também questões como:
- Quando utilizar determinado padrão?
- Quando não utilizar?
- Qual problema ele resolve?
- Qual complexidade ele adiciona?
- Como ele afeta acoplamento e coesão?
- Como impacta testabilidade?
- Quais são os custos de manutenção?
- Como esse padrão se comporta em sistemas distribuídos?
- Existem alternativas melhores utilizando recursos modernos da linguagem ou do framework?
Um Singleton, por exemplo, não deveria ser discutido apenas como:
“garantir que uma classe tenha apenas uma instância”.
Seria interessante discutir também estado global, concorrência, testabilidade, ciclo de vida, injeção de dependência e por que frameworks modernos frequentemente oferecem mecanismos melhores para resolver esse tipo de necessidade.
É justamente nesse tipo de discussão que, na minha opinião, arquitetura começa a deixar de ser apenas implementação e passa a ser tomada de decisão.
Spring Boot também poderia ser explorado de outra perspectiva
O mesmo acontece com Spring Boot.
Aprender @RestController, @Service, JpaRepository, @Column, findById() e outras abstrações é necessário.
Mas isso responde principalmente à pergunta:
“Como faço?”
Em arquitetura, eu esperaria também perguntas como:
“Por que fazer dessa maneira?”
“Qual será o impacto dessa decisão quando o sistema crescer?”
“Como essa aplicação vai se comportar sob carga?”
“Onde entra cache?”
“Como tratar falhas?”
“Como observar o sistema?”
“Como lidar com concorrência?”
“Como separar responsabilidades?”
“Quando uma aplicação Spring Boot deveria deixar de ser um monólito?”
“Quando não deveria ser quebrada em microsserviços?”
“Como lidar com transações distribuídas?”
“Como projetar comunicação síncrona e assíncrona?”
Essas são discussões que considero muito mais próximas do objetivo de uma disciplina de arquitetura.
A carga horária também pesa
Outro ponto que me chamou bastante atenção foi a quantidade de conteúdo em relação à carga horária.
Alguns assuntos são apresentados em aulas extremamente curtas.
Uma aula de poucos minutos pode ser suficiente para apresentar um conceito, mas dificilmente é suficiente para explorar profundamente suas aplicações, limitações e trade-offs.
Na minha percepção, o conteúdo relacionado ao ecossistema Java poderia facilmente ocupar uma carga horária significativamente maior.
Algo na faixa de 48 a 80 horas, por exemplo, permitiria trabalhar os conceitos com muito mais profundidade, principalmente através de exercícios, estudos de caso e projetos práticos.
Talvez minha expectativa também esteja relacionada à experiência profissional
Existe outro fator importante nessa avaliação.
Eu já tive contato profissional com Java, inclusive trabalhando com Java 6 em um projeto na Natura durante minha passagem pela SysMap.
Por isso, alguns conceitos apresentados não eram completamente novos para mim.
Isso naturalmente aumenta minha expectativa em relação ao conteúdo.
Para alguém que está começando no ecossistema Java, a disciplina provavelmente funciona muito bem como uma introdução organizada.
Para alguém que já trabalha com desenvolvimento de software, entretanto, eu esperava que a disciplina avançasse mais rapidamente para os problemas arquiteturais.
O que eu gostaria de ter visto?
Principalmente mais situações reais.
Por exemplo:
Arquitetura
- Monólito vs. microsserviços
- Modularização
- Clean Architecture
- Hexagonal Architecture
- DDD
- Bounded Contexts
- Event-Driven Architecture
- Comunicação síncrona vs. assíncrona
Distribuição
- Consistência
- Idempotência
- Retry
- Circuit Breaker
- Timeout
- Bulkhead
- Rate Limiting
- Mensageria
- Eventual Consistency
Persistência
- Estratégias de cache
- N+1 queries
- Índices
- Transações
- Concorrência
- Connection Pool
- Performance do ORM
- Quando utilizar ou evitar abstrações do JPA
Observabilidade
- Logs estruturados
- Métricas
- Tracing distribuído
- Correlation ID
- Monitoramento
- Diagnóstico de falhas
Segurança
- OAuth2
- JWT
- Controle de acesso
- Gestão de secrets
- Segurança entre serviços
E, principalmente, estudos de caso onde uma decisão arquitetural tivesse consequências reais.
Por exemplo:
“Você possui um sistema que suporta 100 usuários. Agora precisa suportar 100 mil. O que muda?”
Esse tipo de problema gera uma discussão arquitetural muito mais interessante do que simplesmente apresentar uma anotação do Spring.
A crítica é construtiva
Não considero a disciplina ruim.
As explicações são boas, os conceitos apresentados são relevantes e existe valor em organizar esse conhecimento.
Minha crítica é justamente porque acredito que o potencial da disciplina é muito maior.
Em uma graduação, eu consideraria perfeitamente aceitável uma abordagem mais introdutória.
Em uma pós-graduação focada em Arquitetura de Software Distribuído, porém, eu esperava uma discussão mais profunda sobre decisões, consequências e trade-offs.
A diferença entre aprender uma tecnologia e aprender arquitetura, para mim, está justamente aí.
Aprender uma tecnologia é saber utilizá-la.
Aprender arquitetura é saber quando utilizá-la, quando não utilizá-la e entender as consequências dessa escolha.
Essa é a principal reflexão que levo dessa disciplina.
E talvez seja também uma das discussões mais importantes para quem trabalha com engenharia de software atualmente.
