Questão de Arquitetura de Software — Conceitos Básicos em Arquitetura de Software — FUNDATEC 2025
Arquitetura de Software›Conceitos Básicos em Arquitetura de Software
Código
qg468607
Banca
FUNDATEC
Órgão
BRDE
Ano
2025
Nível
Superior
Cargo
Analista de Sistemas - Subárea Desenvolvimento de Sistemas
Segundo Robert Cecil Martin, proponente da arquitetura de software conhecida como Arquitetura Limpa (Clean Architecture), o uso desse padrão favorece, entre outros fatores:
ADisponibilidade do software e independência de frameworks.
BLimitação nas entregas e escalabilidade.
CManutenibilidade do software e segurança da informação.
DReusabilidade de código e testabilidade.
EDependência de banco de dados e modularidade do software.
Revelar gabarito e comentário▾
GabaritoD — Reusabilidade de código e testabilidade.
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”.
Clean Architecture
Gabarito: letra D. A Clean Architecture, proposta por Robert C. Martin, tem como objetivos centrais o desacoplamento entre camadas e a independência de frameworks, banco de dados e detalhes externos. Isso favorece diretamente a reusabilidade de código (módulos podem ser reaproveitados em diferentes contextos) e a testabilidade (cada camada pode ser testada isoladamente). As demais alternativas descrevem benefícios secundários, incorretos ou até contrários aos princípios da Clean Architecture.
Clean Architecture (R. C. Martin): Objetivos centrais (Desacoplamento entre camadas, Independência de frameworks, Independência de banco de dados, Independência de detalhes externos); Benefícios diretos (Reusabilidade de código, Testabilidade); Benefícios secundários/indiretos (Manutenibilidade, Escalabilidade, Entregas frequentes); Não promovidos diretamente (Disponibilidade, Segurança da informação)
Alternativa A — ❌ Incorreta
A independência de frameworks é um dos pilares da Clean Architecture, mas disponibilidade (availability) não é um atributo diretamente promovido por esse padrão arquitetural. Disponibilidade está mais ligada a requisitos não funcionais de infraestrutura (redundância, failover) do que à organização do código. Além disso, a expressão “independência de frameworks” está correta, mas o par completo descaracteriza a alternativa.
Alternativa B — ❌ Incorreta
“Limitação nas entregas” é o oposto do que se espera: a Clean Architecture visa acelerar o desenvolvimento por meio de componentes reutilizáveis e baixo acoplamento, facilitando entregas frequentes. Escalabilidade pode ser um benefício indireto, mas não é o foco principal e, combinada com o termo negativo, torna a alternativa errada.
Alternativa C — ❌ Incorreta
Manutenibilidade é, de fato, um benefício da Clean Architecture, mas segurança da informação não é um fator diretamente favorecido por esse padrão. A segurança depende de preocupações específicas (autenticação, autorização, criptografia) que não são resolvidas pela arquitetura limpa em si. A alternativa mistura um benefício real com outro não relacionado, tornando-a incompleta.
Alternativa D — ✅ Correta ⟵ GABARITO
A reusabilidade de código é um dos principais ganhos, pois os componentes de negócio (entidades e casos de uso) são independentes de frameworks e detalhes externos, podendo ser reutilizados em diferentes aplicações. A testabilidade é outro pilar: a separação em camadas permite testar cada parte de forma isolada (testes unitários, de integração) sem depender de interfaces de usuário ou bancos de dados. Ambas as características estão alinhadas com os objetivos declarados por Robert C. Martin.
Alternativa E — ❌ Incorreta
“Dependência de banco de dados” é exatamente o que a Clean Architecture busca evitar: a regra é que o banco de dados seja um detalhe externo e que o código de negócio não dependa dele. Modularidade, por sua vez, é um benefício, mas o par é incoerente com a filosofia do padrão.