Pular para o conteúdo principal

Questão de Arquitetura de Software — Arquitetura Orientada a Objetos — FGV 2025

Arquitetura de SoftwareArquitetura Orientada a Objetos
Código
fg115296
Banca
FGV
Órgão
MPU
Ano
2025
Nível
Superior
Cargo
Analista do - Desenvolvimento de Sistemas
Após um estudo aprofundado sobre a sistemática de gestão de processos e do sistema digital que a apoia – o SisGEPRO 1.0 –, a Equipe de Soluções Técnicas (EST) identificou que há conceitos do negócio que não são compreendidos por algumas das partes envolvidas na sustentação do sistema, levando a erros de codificação. Assim, dada a complexidade do negócio e a obsolescência do SisGEPRO 1.0, a EST recomendou o desenvolvimento de uma nova versão do sistema – o SisGEPRO 2.0 – aplicando a abordagem Domain-Driven Design (DDD). Em conformidade com o DDD, o arquiteto de software, após a modelagem dos conceitos do domínio, irá:
  1. Aorganizar um repositório (Repository) para que outras camadas tenham acesso à lógica necessária para acesso a objetos;
  2. Bdefinir o modelo de domínio (Domain Model) acoplado às necessidades de armazenamento de objetos e suas referências;
  3. Ccodificar uma fábrica (Factory) para definir a estratégia de criação e armazenamento de objetos do domínio;
  4. Despecificar agregados (Aggregates) para garantir a consistência das mudanças em objetos num modelo com associações complexas;
  5. Eprojetar serviços (Services) para atender a ações que se refiram a Entidades ou Objetos de valor específicos.
Revelar gabarito e comentário

GabaritoD — especificar agregados (Aggregates) para garantir a consistência das mudanças em objetos num modelo com associações complexas;

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”.

Domain-Driven Design: Agregados e Consistência

Gabarito: letra D. Após a modelagem dos conceitos de domínio no Domain-Driven Design (DDD), o arquiteto deve especificar Agregados (Aggregates) para garantir a consistência das mudanças em objetos em um modelo com associações complexas. Esse é o passo natural após identificar Entidades e Objetos de Valor, agrupando-os em clusters com uma raiz que controla o acesso e as invariantes. As demais alternativas tratam de padrões que, embora parte do DDD, não são a atividade imediata de modelagem.

Alternativa A — ❌ Incorreta

Organizar um Repositório (Repository) é uma preocupação de infraestrutura e persistência, não a ação imediata após modelar o domínio. Repositórios são usados para recuperar objetos do domínio, mas vêm depois da definição dos agregados.

Alternativa B — ❌ Incorreta

Definir o modelo de domínio acoplado às necessidades de armazenamento vai contra um dos princípios fundamentais do DDD: o modelo de domínio deve ser independente da infraestrutura (persistência). O correto é manter o modelo puro, sem acoplamento com banco de dados.

Alternativa C — ❌ Incorreta

Uma Fábrica (Factory) é útil para encapsular lógica complexa de criação de objetos, mas não é a principal atividade pós-modelagem. A consistência em associações complexas é tratada por Agregados, não por Factories.

Alternativa D — ✅ Correta ⟵ GABARITO

Especificar Agregados (Aggregates) é o passo correto. Segundo o DDD, um Agregado é um cluster de objetos de domínio (Entidades e Objetos de Valor) que podem ser tratados como uma única unidade. A raiz do agregado (Aggregate Root) é a única porta de entrada para modificações, garantindo a consistência e as invariantes do negócio.

Alternativa E — ❌ Incorreta

Serviços (Services) de domínio são usados para operações que não se encaixam naturalmente em Entidades ou Objetos de Valor, mas não são a primeira ação após a modelagem. A definição de Agregados precede a de Serviços para assegurar que as operações respeitem os limites de consistência.

Gabarito: letra D

Link permanente: /questoes/fg115296