Pular para o conteúdo principal

Questão de Arquitetura de Software — Arquitetura em camadas — FCC 2026

Arquitetura de SoftwareArquitetura em camadas
Código
fc077584
Banca
FCC
Órgão
SEFAZ-SP
Ano
2026
Nível
Superior
Cargo
Auditor Fiscal da Receita Estadual - AFRE - Tecnologia da Informação e Comunicação - Conhecimentos Especificos (P3)
Um órgão fazendário esta modernizando o módulo de cálculo de tributos e deseja separar claramente a lógica das regras fiscais das adaptações necessárias para diferentes bancos de dados usados pelos estados. Considerando que a equipe quer garantir que mudanças na infraestrutura não impactem as regras tributarias centrais, a abordagem arquitetural que atende melhor a essa necessidade é
  1. Aa Arquitetura MVC, concentrando a lógica tributaria em serviços ligados à camada de apresentação da aplicação web, aproveitando os recursos nativos do framework (como filtros, interceptors e validações) para tratar as particularidades de cada banco de dados.
  2. Bconcentrar as regras fiscais em repositórios especializados por tipo de banco de dados, permitindo que cada repositório implemente as regras e consultas de forma otimizada para o SGBD especifico (por exemplo, usando stored procedures ou funções nativas)
  3. Cimplementar a maior parte da lógica fiscal nos controllers das APIs, centralizando ali o fluxo das regras tributarias e das chamadas as diferentes fontes de dados, o que facilitaria a coordenação entre múltiplos bancos de dados sem alterar o domínio existente.
  4. Da arquitetura hexagonal, estruturando o domínio com portas (interfaces) e adaptadores para cada banco de dados, de forma que as regras fiscais permaneçam independentes das tecnologias de persistência.
  5. Edefinir DTOs ricos para transporte de dados entre camadas, adicionando validações e transformações relacionadas as regras fiscais nesses objetos, mantendo a lógica tributaria distribuída entre serviços, controllers e mapeamentos de banco de dados já existentes.
Revelar gabarito e comentário

GabaritoD — a arquitetura hexagonal, estruturando o domínio com portas (interfaces) e adaptadores para cada banco de dados, de forma que as regras fiscais permaneçam independentes das tecnologias de persistência.

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 para separar regras tributárias da infraestrutura de banco de dados

Gabarito: letra D. A necessidade descrita — isolar as regras fiscais centrais das adaptações para diferentes bancos de dados — é exatamente o caso de uso da arquitetura hexagonal (ports and adapters). Nela, o domínio permanece puro, expondo portas (interfaces) que são implementadas por adaptadores específicos para cada tecnologia externa, garantindo que mudanças na infraestrutura não contaminem a lógica de negócio.

A banca testa o conhecimento dos estilos arquiteturais e sua aplicação a um problema real de separação de responsabilidades. A chave é perceber que a solução deve isolar o domínio, não apenas organizar camadas ou distribuir a lógica.

Alternativa A — ❌ Incorreta

Propõe MVC com lógica tributária em serviços ligados à camada de apresentação. No MVC, a camada de apresentação (View) é responsável pela interface, não por regras de negócio. Além disso, a alternativa sugere tratar particularidades de bancos de dados na camada de apresentação, o que viola a separação de responsabilidades e não isola o domínio.

Alternativa B — ❌ Incorreta

Sugere concentrar regras fiscais em repositórios especializados por tipo de banco de dados. Isso acopla as regras à tecnologia de persistência, exatamente o que se quer evitar. A lógica de negócio deve ser independente e não conhecer detalhes de implementação de banco de dados.

Alternativa C — ❌ Incorreta

Centralizar a lógica fiscal nos controllers acopla regras de negócio à camada de controle (que gerencia requisições/respostas). Isso dificulta a manutenção e quebra o princípio da responsabilidade única. Além disso, viola a independência desejada.

Alternativa D — ✅ Correta ⟵ GABARITO

A arquitetura hexagonal (ports and adapters) coloca o domínio no centro. Portas são interfaces que definem contratos de entrada/saída; adaptadores implementam essas interfaces para tecnologias específicas (bancos de dados, APIs, etc.). Dessa forma, as regras fiscais não conhecem detalhes de persistência. Qualquer mudança em banco de dados exige apenas um novo adaptador, sem tocar no domínio.

PEGA ESSA DICA!

A arquitetura hexagonal é frequentemente cobrada em contraste com a arquitetura em camadas. Enquanto a em camadas organiza verticalmente (apresentação → negócio → dados), a hexagonal isola o domínio no centro e usa adaptadores periféricos. Memorize a imagem: o hexágono representa o domínio; as portas são interfaces; os adaptadores conectam cada tecnologia externa.

Alternativa E — ❌ Incorreta

DTOs ricos com validações e transformações apenas distribuem a lógica tributária entre vários pontos (serviços, controllers, mapeamentos). Isso não a isola; ao contrário, espalha as regras e as acopla a detalhes de transporte e persistência.

Conclusão: A única alternativa que garante que as regras fiscais centrais fiquem independentes das tecnologias de banco de dados é a arquitetura hexagonal. Gabarito: letra D.

Link permanente: /questoes/fc077584