Questão de Engenharia de Software — Desenvolvimento de Software — FGV 2024
Engenharia de Software›Desenvolvimento de Software
Código
fg077381
Banca
FGV
Órgão
CVM
Ano
2024
Nível
Superior
Cargo
Analista - Perfil 8 - TI / Sistemas e Desenvolvimento - Tarde
A Equipe de Desenvolvimento de Soluções de Software (EDSS) recebeu a demanda de desenvolvimento de um software complexo e, por isso, pretende utilizar a abordagem Domain Driven Design (DDD).Com foco no modelo de domínio principal, a EDSS assumirá que:
Aa lógica da aplicação deve considerar o modo de persistência de objetos nos repositórios;
Bas entidades serão definidas pelos atributos que as descrevem;
Cos analistas de negócio e de requisitos serão os responsáveis pela definição da Linguagem Ubíqua;
Dos objetos do domínio serão modelados com responsabilidades do próprio armazenamento, mas não da própria exibição;
Euma operação deve ser adicionada ao modelo como uma interface autônoma, declarada como um serviço, quando não for uma reponsabilidade natural de uma Entidade ou de um Objeto de Valor.
Revelar gabarito e comentário▾
GabaritoE — uma operação deve ser adicionada ao modelo como uma interface autônoma, declarada como um serviço, quando não for uma reponsabilidade natural de uma Entidade ou de um Objeto de Valor.
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 (DDD)
Gabarito: letra E. Em DDD, operações que não são responsabilidade natural de uma Entidade ou Objeto de Valor devem ser modeladas como um Serviço de Domínio — uma interface autônoma. As demais alternativas contrariam princípios fundamentais do DDD.
A banca testa o conhecimento dos blocos de construção do DDD: Entidades, Objetos de Valor, Serviços de Domínio e a Linguagem Ubíqua. O erro mais comum é confundir a definição de Entidade (identidade vs. atributos) ou atribuir responsabilidades de infraestrutura ao modelo de domínio.
Alternativa A — ❌ Incorreta
Afirma que a lógica da aplicação deve considerar o modo de persistência. No DDD, o modelo de domínio deve ser persistence-ignorant (ignorante de persistência). A responsabilidade de armazenamento é dos Repositórios, que fazem parte da infraestrutura, não do domínio. A lógica de negócio não deve se preocupar com como os objetos são salvos.
Alternativa B — ❌ Incorreta
Diz que entidades são definidas por seus atributos. Na verdade, uma Entidade é definida por sua identidade única (um ID, por exemplo), que a distingue de outras entidades mesmo que todos os atributos mudem. Um Objeto de Valor, sim, é definido por seus atributos.
Alternativa C — ❌ Incorreta
Atribui a definição da Linguagem Ubíqua a analistas de negócio e de requisitos. A Linguagem Ubíqua é uma linguagem compartilhada por toda a equipe (desenvolvedores, especialistas do domínio, stakeholders). Ela surge da colaboração contínua entre desenvolvedores e experts do domínio, não é imposta por um único grupo.
Alternativa D — ❌ Incorreta
Afirma que objetos de domínio terão responsabilidades de armazenamento. Isso viola a separação de responsabilidades (SRP). No DDD, objetos de domínio (Entidades e Objetos de Valor) encapsulam regras de negócio e comportamento do domínio. O armazenamento é de responsabilidade dos Repositórios; a exibição, das ViewModels ou Apresentação. Objetos de domínio não devem se preocupar com persistência ou exibição.
Alternativa E — ✅ Correta ⟵ GABARITO
Descreve corretamente o Serviço de Domínio. Quando uma operação não se encaixa naturalmente em uma Entidade ou Objeto de Valor (por exemplo, uma transferência bancária que envolve duas contas), ela deve ser modelada como um Serviço de Domínio: uma interface autônoma, sem estado, que orquestra regras de negócio. É um dos blocos fundamentais do DDD.
NÃO CAIA NESSA!
A banca explora confusões clássicas: a) entidade × objeto de valor (B); b) ubiquidade × responsabilidade de definição (C); c) responsabilidade de domínio × infraestrutura (A e D). Memorize: entidade = identidade; objeto de valor = atributos; serviço = operação sem “dono” natural.