No que diz respeito a design de software, julgue o item a seguir.
Um dos princípios do DDD (domain-driven design) é que o software possa ser construído mesmo sem o entendimento do domínio do cliente.
GabaritoE — Errado
❌ ERRADO. O DDD (Domain-Driven Design) é uma abordagem que centra o desenvolvimento na programação de um modelo de domínio que tenha um rico entendimento dos processos e regras de um domínio. Portanto, a afirmação de que o software pode ser construído sem o entendimento do domínio do cliente contraria frontalmente o princípio fundamental do DDD, que é justamente o oposto: o domínio é a base de tudo.
O DDD é uma abordagem de design de software que coloca o domínio do negócio no centro do desenvolvimento. O termo "domínio" refere-se às atividades desempenhadas pelo usuário e à área de interesse destes. O objetivo é criar um modelo de domínio que represente fielmente as regras e processos do negócio, servindo como base para a comunicação entre a equipe técnica e os especialistas do domínio (os clientes).
A ideia central é que o software deve ser um reflexo do negócio, e não uma construção genérica que ignora as particularidades do cliente. Para isso, o DDD se apoia em três pilares fundamentais:
Linguagem ubíqua: uma linguagem compartilhada por todos os membros da equipe e partes interessadas do negócio, garantindo que todos falem sobre o sistema usando o mesmo vocabulário e entendendo o mesmo significado.
Contextos delimitados (bounded contexts): a separação de responsabilidades entre as diferentes partes do sistema, dividindo-o em módulos com responsabilidades claras e distintas.
Mapas de contexto (context maps): utilizados para entender como cada contexto delimitado se comunica com os demais.
Na prática, o DDD exige um profundo entendimento do domínio do cliente. A equipe de desenvolvimento precisa colaborar intensamente com os especialistas do negócio para construir um modelo que capture as regras e processos de forma precisa. Sem esse entendimento, o modelo de domínio seria superficial e o software não atenderia às reais necessidades do cliente.
A pegadinha desta questão está em inverter o princípio central do DDD. A banca afirma que o software pode ser construído "mesmo sem o entendimento do domínio do cliente", quando na verdade o DDD exige esse entendimento como pré-requisito. É uma armadilha clássica de troca de sentido: o candidato que conhece apenas o nome da abordagem, sem compreender sua essência, pode ser induzido a marcar "Certo".
Guarde esta distinção: enquanto metodologias tradicionais podem focar mais em processos e documentação, o DDD é centrado no domínio — o entendimento profundo do negócio é o que guia todo o design do software. É exatamente esse o critério que decide esta questão.
A alternativa afirma que "um dos princípios do DDD é que o software possa ser construído mesmo sem o entendimento do domínio do cliente". Isso é o oposto do que o DDD prega. O DDD é uma abordagem que centra o desenvolvimento na programação de um modelo de domínio que tenha um rico entendimento dos processos e regras de um domínio. O entendimento do domínio é o ponto de partida e o fundamento de todo o design, não algo dispensável. A alternativa inverte completamente o princípio central do DDD.
A alternativa está correta ao afirmar que a afirmação do enunciado é errada. O DDD exige o entendimento do domínio do cliente, pois é a partir dele que se constrói o modelo de domínio, a linguagem ubíqua e os contextos delimitados. Sem esse entendimento, o DDD não faz sentido. Portanto, a afirmação do enunciado é falsa, e a alternativa E (Errado) é o gabarito.
Gabarito: letra E (Errado).
Link permanente: /questoes/ce417744