Questão de Engenharia de Software — Padrões de Projeto (Engenharia de Software) — FCC 2026
Engenharia de Software›Padrões de Projeto (Engenharia de Software)
Código
fc142278
Banca
FCC
Órgão
ARTESP
Ano
2026
Cargo
Esp RT ( )
Uma agência reguladora de transporte está desenvolvendo um sistema para processar solicitações de autorização de linhas interestaduais. O sistema precisa integrar-se com múltiplos provedores externos de validação (ANTT, Receita Federal, sistemas estaduais) e garantir que a lógica de negócio central permaneça isolada dessas dependências externas. A equipe técnica busca implementar uma arquitetura que permita substituir ou adicionar novos adaptadores de integração sem modificar as regras de negócio. A abordagem arquitetural que melhor atende a esse requisito, considerando os princípios de baixo acoplamento e inversão de dependências, é:
APadrão Mediator do GOF estabelecendo um componente centralizador que coordena as interações entre a lógica de negócio e os diversos provedores externos, reduzindo o acoplamento direto através da comunicação intermediada por esse objeto coordenador.
BImplementação baseada no padrão Facade do GOF, criando uma interface unificada que encapsula as complexidades dos subsistemas externos, permitindo que a camada de negócio acesse todos os provedores através de um único ponto de entrada simplificado e coeso.
CUtilização do padrão Strategy do GOF combinado com Factory Method, onde cada provedor externo é representado por uma estratégia concreta que implementa a interface comum de validação, selecionada dinamicamente conforme o contexto da solicitação.
DArquitetura em camadas tradicionais com o padrão Repository do GOF na camada de acesso a dados, isolando as operações de persistência e consulta aos sistemas externos através de abstrações que ocultam os detalhes de implementação específicos de cada provedor.
EArquitetura Hexagonal (Ports and Adapters) onde a lógica de negócio define interfaces de porta (ports) para as operações necessárias, e os adaptadores (adapters) implementam essas interfaces conectando-se aos provedores externos, mantendo o núcleo da aplicação independente de tecnologias específicas.
Revelar gabarito e comentário▾
GabaritoE — Arquitetura Hexagonal (Ports and Adapters) onde a lógica de negócio define interfaces de porta (ports) para as operações necessárias, e os adaptadores (adapters) implementam essas interfaces conectando-se aos provedores externos, mantendo o núcleo da aplicação independente de tecnologias específicas.
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 Hexagonal (Ports and Adapters)
Gabarito: letra E. A Arquitetura Hexagonal (Ports and Adapters) é a abordagem que melhor atende ao requisito de isolar a lógica de negócio das dependências externas, pois define interfaces de porta (ports) no núcleo da aplicação e adaptadores (adapters) que implementam essas interfaces para conectar-se aos provedores externos, garantindo baixo acoplamento e inversão de dependências. Essa é a essência do padrão, que prioriza a independência do núcleo em relação a tecnologias específicas.
O problema apresentado é clássico em arquitetura de software: como integrar um sistema com múltiplos provedores externos (ANTT, Receita Federal, sistemas estaduais) sem que a lógica de negócio central fique acoplada a essas dependências. A solução exige que o núcleo da aplicação defina contratos (interfaces) para as operações de que necessita, e que as implementações concretas desses contratos sejam fornecidas por componentes externos, plugáveis e substituíveis. É exatamente isso que a Arquitetura Hexagonal, também conhecida como Ports and Adapters, propõe.
O nome "hexagonal" vem da representação visual do padrão, onde o núcleo da aplicação (a lógica de negócio) é desenhado no centro de um hexágono, e cada lado do hexágono representa uma "porta" (port) de interação com o mundo externo. As portas são interfaces que definem o que o núcleo precisa ou oferece, sem especificar como isso é implementado. Os "adaptadores" (adapters) são as implementações concretas dessas portas, responsáveis por conectar o núcleo a tecnologias específicas, como bancos de dados, APIs REST, sistemas legados ou provedores externos de validação.
A grande vantagem dessa arquitetura é a inversão de dependências: o núcleo da aplicação não depende de nenhuma tecnologia externa; pelo contrário, são os adaptadores que dependem das portas definidas pelo núcleo. Isso permite que novos provedores sejam adicionados ou substituídos simplesmente criando novos adaptadores, sem modificar a lógica de negócio. É a materialização do princípio da Inversão de Dependência (DIP) do SOLID, aplicado em nível arquitetural.
Na prática, imagine que o sistema da agência reguladora precise validar uma solicitação de linha interestadual. O núcleo da aplicação define uma porta ValidadorExterno com um método validar(solicitacao). Para cada provedor (ANTT, Receita Federal, sistemas estaduais), é criado um adaptador que implementa essa porta, encapsulando a comunicação específica com cada sistema. Se um novo provedor for adicionado, basta criar um novo adaptador; o núcleo permanece intacto. Essa é a essência da Arquitetura Hexagonal.
A pegadinha desta questão está em confundir a Arquitetura Hexagonal com padrões de projeto GoF (como Facade, Mediator ou Strategy) que resolvem problemas de escopo menor, ou com outras arquiteturas (como camadas) que não isolam o núcleo de forma tão eficaz. A banca explora a diferença entre um padrão de projeto (solução de escopo local) e um padrão arquitetural (solução de escopo global). Guarde essa distinção: é exatamente nela que as alternativas se dividem.
Critério
Arquitetura Hexagonal (E)
Facade (B)
Strategy + Factory (C)
Escopo
Arquitetural (global)
Padrão de projeto estrutural (local)
Padrões de projeto comportamental/criacional (local)
Inversão de dependência
Sim — núcleo define portas; adaptadores dependem das portas
Não — núcleo depende da fachada, que depende dos subsistemas
Parcial — estratégias implementam interface, mas não há isolamento arquitetural do núcleo
Substituição de provedores externos
Adiciona/substitui adaptadores sem tocar no núcleo
Troca de provedor exige alteração na fachada
Troca de estratégia é dinâmica, mas não isola o núcleo de outras dependências
Acoplamento com tecnologias externas
Núcleo totalmente desacoplado
Núcleo ainda acoplado à fachada
Núcleo acoplado à seleção de estratégias
Adequação ao requisito (múltiplos provedores)
Alta — projetado para múltiplos adaptadores plugáveis
Média — simplifica acesso, mas não isola o núcleo
Média — resolve seleção, não integração arquitetural
Alternativa A — ❌ Incorreta
O padrão Mediator do GoF é um padrão de comportamento que centraliza a comunicação entre objetos, reduzindo o acoplamento direto entre eles. No entanto, ele não é uma abordagem arquitetural para isolar a lógica de negócio de dependências externas. O Mediator resolve um problema de comunicação entre objetos de um mesmo domínio, não entre o núcleo da aplicação e provedores externos. A descrição da alternativa confunde o escopo do padrão (comunicação entre objetos) com o escopo arquitetural (isolamento do núcleo).
Alternativa B — ❌ Incorreta
O padrão Facade do GoF é um padrão estrutural que fornece uma interface unificada e simplificada para um conjunto de interfaces de um subsistema. Ele esconde a complexidade do subsistema, mas não promove a inversão de dependências nem isola a lógica de negócio de forma arquitetural. O Facade simplifica o acesso, mas o núcleo ainda depende diretamente da fachada, que por sua vez depende dos subsistemas. Não é a abordagem que melhor atende ao requisito de baixo acoplamento e inversão de dependências.
Alternativa C — ❌ Incorreta
A combinação de Strategy com Factory Method é uma solução válida para selecionar dinamicamente algoritmos ou estratégias em tempo de execução. No entanto, ela resolve um problema de escopo local (seleção de comportamento) e não estabelece uma arquitetura que isole o núcleo da aplicação das dependências externas. O Strategy permite trocar a lógica de uma operação, mas não define uma estrutura arquitetural para integração com múltiplos provedores externos. A descrição da alternativa confunde o uso de padrões de projeto com a adoção de um padrão arquitetural.
Alternativa D — ❌ Incorreta
A arquitetura em camadas com o padrão Repository é uma abordagem comum, mas o Repository é um padrão de projeto que isola a camada de acesso a dados, não a lógica de negócio de dependências externas em geral. Além disso, a arquitetura em camadas tradicionais tende a criar dependências entre camadas adjacentes, o que pode não garantir o baixo acoplamento desejado. O Repository é útil para persistência, mas não é a solução arquitetural mais adequada para integrar múltiplos provedores externos de validação.
Alternativa E — ✅ Correta ⟵ GABARITO
A Arquitetura Hexagonal (Ports and Adapters) é exatamente a abordagem que atende ao requisito. O núcleo da aplicação define interfaces de porta (ports) para as operações necessárias, e os adaptadores (adapters) implementam essas interfaces, conectando-se aos provedores externos. Isso mantém o núcleo independente de tecnologias específicas, garantindo baixo acoplamento e inversão de dependências. A descrição da alternativa espelha perfeitamente os conceitos fundamentais do padrão.