Questão de Tecnologia da Informação · FGV CVM 2024 (nº 5)

No Domain Driven Design (DDD), o foco é criar um modelo de software que reflita de perto a lógica e os conceitos do negócio (o "domínio"). Para isso, o DDD define diferentes tipos de objetos para representar essa lógica, como Entidades, Objetos de Valor e Serviços de Domínio.

(A) Incorreta: A lógica de domínio deve ser agnóstica à persistência. Misturar preocupações de persistência (como salvar dados) com a lógica de negócio principal é uma anti-prática que viola o princípio da separação de responsabilidades.
(B) Incorreta: Entidades em DDD são definidas primeiramente por sua identidade e comportamento (o que elas fazem), e não apenas pelos atributos que as descrevem (o que elas são). Focar apenas em atributos pode levar a um "Modelo de Domínio Anêmico", onde a lógica de negócio está fora das entidades. Armadilha: Em modelagem de dados tradicional, atributos são o ponto de partida, mas em DDD, o comportamento é crucial para entidades.
(C) Incorreta: A Linguagem Ubíqua é uma linguagem compartilhada e desenvolvida por todos os membros da equipe (especialistas de domínio, desenvolvedores, testadores, etc.) para garantir que todos entendam os termos do negócio da mesma forma. Não é responsabilidade exclusiva de analistas.
(D) Incorreta: Objetos de domínio não devem ter responsabilidades de armazenamento (persistência) nem de exibição (interface do usuário). Essas são preocupações de infraestrutura e apresentação, respectivamente, e devem ser separadas do modelo de domínio puro para manter sua coesão e foco na lógica de negócio.
(E) Correta: Esta alternativa descreve perfeitamente o papel de um Serviço de Domínio. Quando uma operação de negócio importante não se encaixa naturalmente como um comportamento de uma única Entidade ou Objeto de Valor (por exemplo, envolve a coordenação de várias entidades ou representa uma ação que não pertence a um objeto específico), ela deve ser modelada como um Serviço de Domínio.