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á:
- A)organizar um repositório (Repository) para que outras camadas tenham acesso à lógica necessária para acesso a objetos;
Errada, porque Repository abstrai o acesso a dados e a recuperação de agregados, não expõe uma lógica para outras camadas acessarem objetos.
- B)definir o modelo de domínio (Domain Model) acoplado às necessidades de armazenamento de objetos e suas referências;
Errada, porque o Domain Model em DDD deve refletir o negócio e não ficar acoplado às necessidades de armazenamento ou referências da persistência.
- C)codificar uma fábrica (Factory) para definir a estratégia de criação e armazenamento de objetos do domínio;
Errada, porque Factory ajuda na criação de objetos do domínio, mas não define estratégia de armazenamento de objetos.
- D)especificar agregados (Aggregates) para garantir a consistência das mudanças em objetos num modelo com associações complexas;
Certa, porque Aggregates delimitam uma unidade de consistência e garantem que mudanças em objetos com relações complexas respeitem as regras do domínio.
- E)projetar serviços (Services) para atender a ações que se refiram a Entidades ou Objetos de valor específicos.
Errada, porque Services em DDD tratam operações do domínio que não se encaixam bem em uma Entidade ou Objeto de Valor, e não ações referentes a eles especificamente.
Gabarito: D
No Domain-Driven Design (DDD), a ideia central é fazer o software conversar em linguagem do negócio e organizar o código de acordo com os conceitos reais do domínio. Isso ajuda a reduzir aquele clássico desastre de sistema em que cada área entende uma coisa e o código implementa outra. Em vez de começar pensando só em tabelas e persistência, o foco inicial é o modelo do domínio, ou seja, as entidades, objetos de valor, serviços de domínio, agregados e suas regras. Nesse contexto, o ponto mais importante da questão é o agregado. Um agregado é um conjunto de objetos do domínio tratados como uma unidade de consistência. Ele tem uma raiz, chamada Aggregate Root, e é por meio dela que as regras de alteração são aplicadas. A sacada é simples: se o negócio tem associações complexas e várias partes mudando ao mesmo tempo, o agregado ajuda a manter a consistência sem deixar o sistema virar um carnaval de dependências soltas. Por isso o gabarito é a letra D. Em DDD, agregados são especificados justamente para garantir que as mudanças feitas em objetos relacionados respeitem as regras do domínio e não deixem o estado inconsistente. A doutrina do DDD, popularizada por Eric Evans, trata agregados como fronteiras de consistência e de transação dentro do modelo. As outras alternativas misturam conceitos corretos de DDD, mas com definições tortas. Repositório não é para dar acesso à lógica de objetos, e sim para abstrair a persistência e recuperar agregados. Fábrica serve para criação de objetos complexos, não para estratégia de armazenamento. Serviço de domínio atende a operações do domínio que não pertencem naturalmente a uma entidade ou objeto de valor específico. E o modelo de domínio não deve nascer acoplado ao armazenamento, porque isso é justamente um dos vícios que o DDD tenta evitar.