Questão de Engenharia de Software — Geral — INSTITUTO AOCP 2024

Domain-Driven Design (DDD): contextos delimitados

Gabarito: letra E. O DDD (Domain-Driven Design) é uma abordagem que centra o desenvolvimento na modelagem do domínio do negócio, e um de seus pilares fundamentais é a divisão do sistema em contextos delimitados (bounded contexts) — módulos distintos que refletem áreas específicas do domínio, como contratos, clientes e pagamentos. As demais alternativas contrariam diretamente os princípios do DDD ao propor centralização, isolamento ou generalização excessiva.

O DDD, criado por Eric Evans, parte da premissa de que o software deve refletir fielmente o domínio do negócio em que atua. Para isso, ele se apoia em três pilares essenciais: a linguagem ubíqua, os contextos delimitados e os mapas de contexto. A linguagem ubíqua é um vocabulário compartilhado entre todos os envolvidos (desenvolvedores, especialistas de negócio, stakeholders), garantindo que todos falem a mesma língua e evitem ambiguidades. Os contextos delimitados, por sua vez, são a materialização da separação de responsabilidades: o sistema é dividido em módulos, cada um com uma responsabilidade clara e distinta, refletindo uma área específica do domínio. Por fim, os mapas de contexto descrevem como esses módulos se comunicam entre si, estabelecendo as relações de interdependência.

A ideia central é que um sistema complexo, como o gerenciamento de contratos com múltiplos departamentos e regras de negócio variadas, não deve ser tratado como um bloco monolítico. Ao contrário, cada área de interesse do negócio — contratos, clientes, pagamentos — constitui um contexto delimitado próprio, com seu próprio modelo de domínio, suas próprias regras e sua própria terminologia. Isso simplifica o entendimento, facilita a manutenção e permite que cada módulo evolua de forma independente, desde que respeitados os contratos de comunicação estabelecidos nos mapas de contexto.

Na prática, imagine o sistema de contratos: o módulo de "Contratos" gerencia a criação, vigência e renovação de contratos; o módulo de "Clientes" cuida do cadastro e das informações dos clientes; o módulo de "Pagamentos" trata das faturas, cobranças e recebimentos. Cada um desses módulos tem seu próprio modelo de domínio, com entidades e regras específicas. A comunicação entre eles é definida pelos mapas de contexto, que podem estabelecer, por exemplo, que o módulo de Pagamentos consulte o módulo de Contratos para saber quais contratos estão ativos. Essa separação é o que permite que mudanças em um módulo não impactem diretamente os outros, desde que os contratos de comunicação sejam mantidos.

A pegadinha que a banca explora neste tema é a confusão entre DDD e outras abordagens de desenvolvimento. O candidato pode ser tentado a escolher alternativas que defendem a centralização (módulo único, repositório global) ou o isolamento total (evitar comunicação), mas ambas contrariam o DDD. O DDD não prega o isolamento, mas sim a separação com comunicação bem definida. Também não prega a generalização, mas sim a especialização por contexto. Guarde essa distinção: é exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Implementar todas as funcionalidades em um único módulo contraria frontalmente o princípio dos contextos delimitados. O DDD prega exatamente o oposto: a divisão do sistema em módulos distintos, cada um com responsabilidade clara e específica. Um módulo único monolítico dificulta a manutenção, aumenta o acoplamento e torna o sistema mais complexo de entender e evoluir — justamente o que o DDD busca evitar.

Alternativa B — ❌ Incorreta

Definir todas as entidades e serviços em um único repositório global é o oposto da separação de responsabilidades que o DDD preconiza. Cada contexto delimitado deve ter seu próprio modelo de domínio, com suas próprias entidades, repositórios e serviços. Um repositório global misturaria conceitos de domínios diferentes, criando um modelo confuso e acoplado, violando a essência do DDD.

Alternativa C — ❌ Incorreta

Evitar a comunicação entre módulos é um equívoco. O DDD não prega o isolamento, mas sim a comunicação bem definida entre os contextos delimitados, descrita nos mapas de contexto. Os módulos precisam se comunicar para que o sistema funcione como um todo; o que o DDD busca é que essa comunicação seja explícita, controlada e respeite os limites de cada contexto. A alternativa confunde "separação de responsabilidades" com "isolamento total", que não é um princípio do DDD.

Alternativa D — ❌ Incorreta

Utilizar um modelo genérico para representar todos os elementos do sistema contraria a ideia de que cada contexto delimitado deve ter seu próprio modelo de domínio, especializado e rico em regras de negócio. O DDD valoriza a especialização: cada módulo modela seu domínio específico com entidades, value objects e serviços próprios. Um modelo genérico único empobreceria a representação do domínio, perdendo as particularidades de cada área de negócio.

Alternativa E — ✅ Correta ⟵ GABARITO

Esta alternativa espelha com precisão o princípio dos contextos delimitados do DDD. Dividir o sistema em módulos distintos, onde cada um reflete um contexto delimitado específico do domínio (contratos, clientes, pagamentos), é exatamente o que o DDD preconiza. Cada módulo terá seu próprio modelo de domínio, suas regras e sua linguagem ubíqua, e a comunicação entre eles será definida pelos mapas de contexto. É a aplicação correta dos princípios do DDD no desenvolvimento do sistema de gerenciamento de contratos.

Gabarito: letra E