Questão de Engenharia de Software — DDD (Domain-Driven Design) — CESPE / CEBRASPE 2024
Engenharia de Software›DDD (Domain-Driven Design)
Código
ce403901
Banca
CESPE / CEBRASPE
Órgão
STJ
Ano
2024
Cargo
AJ
No que concerne a DDD (domain-driven design), julgue os itens subsecutivos.
Em DDD, os diagramas são elaborados com linguagem ubíqua, que é uma linguagem de marcação semelhante ao XML.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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”.
DDD (Domain-Driven Design): linguagem ubíqua
Gabarito: Errado (E). A linguagem ubíqua do DDD não é uma linguagem de marcação semelhante ao XML — ela é um vocabulário compartilhado entre a equipe de desenvolvimento e as partes interessadas do negócio, que incorpora a terminologia do domínio. A afirmação confunde o conceito de linguagem ubíqua com uma tecnologia de representação de dados, o que é um equívoco conceitual.
O Domain-Driven Design (DDD) é uma abordagem de desenvolvimento de software 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 domínio, por sua vez, são as atividades desempenhadas pelo usuário e a área de interesse destes. O DDD busca representar esse domínio em um modelo, abstraindo a complexidade do negócio através de uma representação simplificada.
O DDD é baseado em três pilares fundamentais:
Linguagem ubíqua: uma linguagem compartilhada por todos os membros da equipe de desenvolvimento e partes interessadas do negócio, que incorpora a terminologia do domínio. Ela garante que todos estejam falando sobre o sistema usando o mesmo vocabulário e entendendo o mesmo significado, evitando mal-entendidos e ambiguidades.
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, e como funcionam de maneira interdependente.
A linguagem ubíqua é um conceito de comunicação e modelagem, não uma tecnologia de marcação. XML (Extensible Markup Language) é uma linguagem de marcação que define regras para codificar documentos em um formato legível tanto por humanos quanto por máquinas. A confusão entre os dois conceitos é a pegadinha central desta questão: a banca tenta associar a linguagem ubíqua a uma tecnologia de representação de dados, quando na verdade ela é um vocabulário compartilhado.
Para fixar o contraste:
Critério
Linguagem ubíqua
XML
Natureza
Vocabulário compartilhado
Linguagem de marcação
Objetivo
Comunicação e alinhamento de entendimento
Representação e transporte de dados
Uso no DDD
Pilar do DDD
Não faz parte do DDD
A pegadinha da banca é clássica: trocar um conceito de comunicação por uma tecnologia de representação. O candidato que conhece apenas o nome "linguagem ubíqua" e associa "linguagem" a "linguagem de marcação" cai no erro. Mas quem entende que a linguagem ubíqua é um vocabulário compartilhado para alinhar o entendimento do domínio entre todos os envolvidos percebe imediatamente a inconsistência da afirmação.
Linguagem ubíqua (DDD): Natureza (Vocabulário compartilhado, Equipe + partes interessadas); Objetivo (Alinhar entendimento do domínio, Evitar ambiguidades); Não é (Linguagem de marcação, Semelhante ao XML)
Item — ❌ Errado
A afirmação está errada porque define a linguagem ubíqua como "uma linguagem de marcação semelhante ao XML". Isso é um equívoco conceitual: a linguagem ubíqua é um vocabulário compartilhado entre a equipe e as partes interessadas, que incorpora a terminologia do domínio para garantir comunicação e entendimento uniformes. Ela não tem relação com linguagens de marcação como XML, que são tecnologias para representar e transportar dados estruturados.