Questão de Arquitetura de Software — Arquitetura em camadas — IV - UFG 2026
Arquitetura de Software›Arquitetura em camadas
Código
qg732561
Banca
IV - UFG
Órgão
UFSCAR
Ano
2026
Nível
Superior
Cargo
Analista de TI
No desenvolvimento de aplicações SaaS com o framework Angular em combinação com o framework Spring Boot, qual seria uma prática apropriada de uso desses frameworks?
AImplementar as regras de domínio de negócio com Angular para facilitar sua adaptação a diferentes clientes, enquanto o back-end, implementado com Spring Boot, deve se limitar a operações CRUD e acesso ao banco de dados, de modo a facilitar a evolução da aplicação.
BImplementar as regras de negócio no back-end com Spring Boot para garantir segurança e reutilização por múltiplos clientes, enquanto a lógica de apresentação e de controle da interface de usuário deve ser implementada com Angular para garantir a interatividade da aplicação.
CImplementar as regras de validação e controle de acesso no front-end com Angular, pois a separação entre cliente e servidor já garante a consistência e segurança dos dados, enquanto o back-end, baseado em Spring Boot deve expor a lógica da aplicação por meio de APIs REST padronizadas.
DImplementar o acesso aos dados no front-end com Angular, de modo que validações de dados específicas de usuário possam ser feitas sem gerar sobrecarga no servidor e que a lógica de negócio, implementada no back-end com Spring Boot possa ser independente do esquema do banco de dados.
Revelar gabarito e comentário▾
GabaritoB — Implementar as regras de negócio no back-end com Spring Boot para garantir segurança e reutilização por múltiplos clientes, enquanto a lógica de apresentação e de controle da interface de usuário deve ser implementada com Angular para garantir a interatividade da aplicação.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Arquitetura de Software: Angular + Spring Boot
Gabarito: letra B. A prática apropriada é implementar as regras de negócio no back-end (Spring Boot) para garantir segurança e reutilização por múltiplos clientes, enquanto a lógica de apresentação e controle da interface fica no front-end (Angular). Essa separação segue o princípio de responsabilidade única da arquitetura em camadas, onde cada camada tem seu papel bem definido.
Em aplicações SaaS com Angular e Spring Boot, a divisão clássica é:
Angular (front-end): camada de apresentação e controlador da interface do usuário.
Spring Boot (back-end): camada de aplicação, contendo as regras de negócio e acesso a dados, expondo APIs REST.
A banca testa o conhecimento de onde cada responsabilidade deve estar. Alternativas que colocam lógica de negócio no front-end ou acesso a dados no cliente estão erradas, pois comprometem segurança e manutenibilidade.
NÃO CAIA NESSA!
A banca inverte os papéis, fazendo o candidato achar que regras de negócio podem ficar no Angular para "facilitar adaptação" (A) ou que validações de segurança podem ser só no front-end (C). Lembre-se: o back-end é o guardião das regras de negócio e da segurança; o front-end cuida da interação com o usuário.
Aspecto
Alternativa A (❌)
Alternativa B (✅)
Alternativa C (❌)
Alternativa D (❌)
Local das regras de negócio
Angular (front-end)
Spring Boot (back-end)
Spring Boot (back-end)
Spring Boot (back-end)
Local da lógica de apresentação/controle
Angular (front-end)
Angular (front-end)
Angular (front-end)
Angular (front-end)
Local do acesso a dados
Spring Boot (back-end)
Spring Boot (back-end)
Spring Boot (back-end)
Angular (front-end)
Local das validações/controle de acesso
Não especificado
Spring Boot (back-end)
Angular (front-end)
Angular (front-end)
Segurança
Comprometida (regras expostas)
Garantida (back-end)
Comprometida (validações no front-end)
Comprometida (acesso a dados no front-end)
Reutilização por múltiplos clientes
Difícil (regras no front-end)
Fácil (regras no back-end)
Fácil (regras no back-end)
Difícil (acesso a dados no front-end)
Princípio violado
Separação de responsabilidades
Nenhum (correto)
Segurança em profundidade
Separação de responsabilidades
Alternativa A — ❌ Incorreta
Coloca as regras de domínio no Angular. Isso expõe a lógica de negócio ao cliente, dificulta a reutilização por outros clientes (cada front-end teria que replicar) e fere a segurança, já que o código front-end é visível no navegador. O back-end não deve se limitar a CRUD; deve conter a inteligência do negócio.
Alternativa B — ✅ Correta ⟵ GABARITO
Separa corretamente: regras de negócio no Spring Boot (segurança, reutilização) e lógica de apresentação/controle no Angular (interatividade). Isso alinha com os princípios de arquitetura em camadas e com o padrão MVC, onde o Model (regras) fica no servidor e a View/Controller no cliente.
Alternativa C — ❌ Incorreta
Afirma que "a separação entre cliente e servidor já garante consistência e segurança", o que é falso. Validações e controle de acesso no front-end são facilmente contornáveis. Essas responsabilidades devem ser implementadas no back-end. A afirmação de que o back-end expõe lógica via REST está correta, mas o erro está na segurança delegada ao front-end.
Alternativa D — ❌ Incorreta
Propõe "implementar o acesso aos dados no front-end", o que é grave erro de arquitetura. O acesso a dados (repositórios, DAOs) deve ficar no back-end, protegido e centralizado. Validações específicas de usuário podem ser feitas no front-end para usabilidade, mas não substituem as validações no servidor. A lógica de negócio independente do esquema de banco é desejável, mas o acesso a dados no front-end invalida a alternativa.