No que concerne a DDD (domain-driven design), julgue os itens subsecutivos.
Conforme o conceito de bounded contexts, os contextos da aplicação têm regras e responsabilidades claramente definidas, representadas em um context map.
GabaritoC — Certo
Gabarito: Certo (C). A afirmação está correta: no DDD, os bounded contexts (contextos delimitados) são unidades com regras e responsabilidades claramente definidas, e o context map (mapa de contexto) é exatamente a representação desses contextos e de seus relacionamentos. A assertiva espelha fielmente os pilares do DDD descritos na literatura da área.
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 DDD é baseado em três pilares fundamentais: a linguagem ubíqua, os contextos delimitados (bounded contexts) e os mapas de contexto (context maps).
A linguagem ubíqua é uma linguagem compartilhada por todos os membros da equipe de desenvolvimento e partes interessadas do negócio, incorporando a terminologia do domínio nos sistemas de software. Ela ajuda a garantir que todos estejam falando sobre o sistema usando o mesmo vocabulário e entendendo o mesmo significado, evitando mal-entendidos e ambiguidades.
Os contextos delimitados (bounded contexts) enfatizam a separação de responsabilidades entre as diferentes partes do sistema. O DDD divide o sistema em diferentes módulos, cada um com uma responsabilidade clara e distinta. Isso simplifica o sistema e o torna mais fácil de entender e manter ao longo do tempo. Cada contexto delimitado possui seu próprio modelo de domínio, sua própria linguagem ubíqua e suas próprias regras de negócio.
Os mapas de contexto (context maps) são utilizados para entender como cada contexto delimitado se comunica com os demais contextos delimitados e, consequentemente, como eles estão funcionando de maneira interdependente. O context map é uma representação visual que mostra os contextos delimitados e os relacionamentos entre eles, como partnership, shared kernel, customer-supplier, conformist, anticorruption layer, open host service e published language.
A questão afirma que "os contextos da aplicação têm regras e responsabilidades claramente definidas, representadas em um context map". Isso está perfeitamente alinhado com os conceitos: os bounded contexts são as unidades com regras e responsabilidades definidas, e o context map é a representação desses contextos e de seus relacionamentos. A banca não inverteu nenhum conceito; a afirmação é uma descrição correta dos pilares do DDD.
A pegadinha que a banca poderia explorar, mas não explorou aqui, seria inverter os papéis: dizer que o context map define as regras e responsabilidades, quando na verdade quem define são os bounded contexts. Ou ainda, confundir bounded context com context map, tratando-os como sinônimos. Nesta questão, porém, a afirmação está correta.
A afirmação está correta. Os bounded contexts são, de fato, contextos da aplicação com regras e responsabilidades claramente definidas. O context map é a representação desses contextos e de seus relacionamentos, mostrando como eles se comunicam e funcionam de maneira interdependente. A assertiva descreve com precisão os dois pilares do DDD.
Gabarito: Certo (C).
Link permanente: /questoes/ce403900