Questão de Arquitetura de Software — Arquitetura em camadas — Instituto Darwin 2025
Arquitetura de Software›Arquitetura em camadas
Código
qg560160
Banca
Instituto Darwin
Órgão
CREA-PB
Ano
2025
Nível
Superior
Cargo
Analista de Sistema
Em um projeto corporativo desenvolvido em C# sob arquitetura multicamadas, o analista identifica que determinadas classes da camada de domínio estão violando o princípio de inversão de dependência (DIP) ao instanciar diretamente classes da camada de infraestrutura. Considerando as boas práticas de desenvolvimento orientado a objetos e a aplicação de padrões de projeto, qual seria a solução mais aderente para restabelecer o baixo acoplamento e a alta coesão entre as camadas?
AIntroduzir interfaces na camada de domínio e injetá-las via construtor com uso de inversão de controle (IoC).
BMover toda a lógica de negócio para a camada de infraestrutura, eliminando dependências cruzadas.
CAplicar herança múltipla para reutilizar métodos comuns entre as camadas.
DCentralizar todas as dependências em uma classe estática “DependencyManager”.
EImplementar acoplamento direto com uso de variáveis globais controladas pelo compilador.
Revelar gabarito e comentário▾
GabaritoA — Introduzir interfaces na camada de domínio e injetá-las via construtor com uso de inversão de controle (IoC).
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”.
Princípio de Inversão de Dependência (DIP) e Inversão de Controle (IoC)
Gabarito: letra A. A violação do DIP (Dependency Inversion Principle) ocorre quando classes de alto nível dependem diretamente de classes de baixo nível. A solução clássica é introduzir abstrações (interfaces) na camada de domínio e utilizar Inversão de Controle (IoC) para injetar as implementações da infraestrutura, promovendo baixo acoplamento e alta coesão.
A questão aborda um problema comum em arquiteturas multicamadas: a dependência direta da camada de domínio em relação à infraestrutura. A resposta correta está alinhada com as boas práticas de design orientado a objetos e os padrões de projeto, especialmente o Princípio de Inversão de Dependência (DIP) do SOLID e o padrão Injeção de Dependência (DI).
DIP (Dependency Inversion Principle)
1Problema
Classe de alto nível (domínio)
Depende diretamente de
Classe de baixo nível (infraestrutura)
2Solução (DIP + IoC)
Abstração (interface) no domínio
Implementação na infraestrutura
Injeção via construtor
Resultado
Baixo acoplamento
Alta coesão
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
Introduzir interfaces na camada de domínio e utilizar injeção por construtor com IoC é exatamente a aplicação do DIP. As abstrações (interfaces) são definidas onde são usadas (domínio) e as implementações concretas (infraestrutura) são injetadas, invertendo o fluxo de dependência. Isso reduz o acoplamento e aumenta a coesão, pois as classes de domínio passam a depender de abstrações, não de implementações.
Alternativa B — ❌ Incorreta
Mover toda a lógica de negócio para a camada de infraestrutura viola a separação de responsabilidades e a coesão. A camada de domínio deve conter as regras do negócio, enquanto a infraestrutura lida com detalhes técnicos. Essa abordagem aumenta o acoplamento e dificulta a manutenção e evolução.
Alternativa C — ❌ Incorreta
Herança múltipla não é suportada em C# (apenas herança simples) e, mesmo em linguagens que a suportam, não resolve o problema de dependência direta entre camadas. Reutilização via herança não promove desacoplamento; pelo contrário, pode aumentar o acoplamento.
Alternativa D — ❌ Incorreta
Centralizar dependências em uma classe estática (como um gerenciador de dependências) é uma forma de Service Locator, considerado um antipadrão em comparação com a injeção de dependência. Isso ainda cria acoplamento com o gerenciador, dificulta testes e vai contra a inversão de controle.
Alternativa E — ❌ Incorreta
Variáveis globais aumentam o acoplamento, quebram o encapsulamento e tornam o código difícil de testar e manter. É o oposto do que se busca em uma arquitetura bem projetada.