Design Orientado por Domínio (ou DDD, Domain Driven Design) é uma metodologia de desenvolvimento de software que visa criar um modelo de software que corresponda ao domínio de negócios. Com relação a Design Orientado por Domínio, analise os itens a seguir I. O DDD se opõe à ideia de ter um único modelo para todo o sistema; em vez disso, incentiva a divisão do sistema em contextos limitados, cada um dos quais tem seu próprio modelo. II. Durante a fase estratégica de DDD, você está mapeando fora do domínio empresarial e definindo contextos limitados para seus modelos de domínio. III. DDD tático é quando você define os modelos de domínio com mais precisão, sendo estes padrões aplicados dentro de um único contexto limitado. Está correto o que se afirma em
- A)I, apenas.
Errada, porque o DDD não defende um único modelo para todo o sistema, e os itens II e III também estão corretos.
- B)II, apenas.
Errada, porque a fase estratégica realmente existe no DDD, mas a afirmação é incompleta ao ignorar os demais itens corretos.
- C)III, apenas.
Errada, porque o DDD tático está corretamente descrito, mas os itens I e II também são verdadeiros.
- D)I e III, apenas.
Errada, porque além de I e III estarem corretos, o item II também está correto.
- E)I, II e III.
Certa, porque os três itens descrevem corretamente os níveis estratégico e tático do DDD.
Gabarito: E
O DDD, ou Domain Driven Design, parte da ideia de que software bom nasce quando o modelo do sistema conversa de verdade com o negócio. Em vez de tentar enfiar tudo em um modelo único e gigante, ele separa o problema em contextos limitados, os famosos bounded contexts, cada um com suas regras e linguagem próprias. Isso ajuda a evitar aquela salada de significados em que a mesma palavra quer dizer coisas diferentes em partes diferentes do sistema. Na visão estratégica do DDD, você olha para o domínio como um todo, identifica as áreas do negócio e define os contextos limitados, além de suas relações. É como organizar o mapa antes de sair construindo a cidade. Já na visão tática, você entra no contexto específico e trabalha nos padrões de modelagem mais concretos, como entidades, value objects, agregados, repositórios, services e factories. Por isso, os três itens estão corretos. O item I acerta ao dizer que o DDD rejeita a ideia de um modelo único para tudo e incentiva múltiplos contextos limitados. O item II também está correto, porque a fase estratégica realmente envolve mapear o domínio e delimitar esses contextos. O item III está certo ao diferenciar o DDD tático, que trata da modelagem interna de cada bounded context. Em resumo: DDD não é só desenhar classe bonitinha, é entender o negócio e deixar o software falar a mesma língua. A banca acertou ao considerar verdadeiras as três afirmações.