Questão de Engenharia de Software — DDD (Domain-Driven Design) — FGV 2023

Relacionamentos entre Bounded Contexts no DDD

Gabarito: letra B. No Domain-Driven Design, quando dois bounded contexts dependem mutuamente um do outro e as equipes precisam colaborar de forma coordenada para alinhar necessidades, o relacionamento é do tipo partnership (parceria). A dependência mútua entre Patrimonial e Financeiro exige que as equipes trabalhem em conjunto, o que caracteriza exatamente esse padrão de contexto.

O DDD (Domain-Driven Design) é uma abordagem de desenvolvimento que centra o software no modelo de domínio, ou seja, nas regras e processos do negócio. Para lidar com a complexidade, o DDD divide o sistema em bounded contexts (contextos delimitados), cada um com sua própria linguagem ubíqua e modelo de domínio. A comunicação entre esses contextos é mapeada por meio de context maps, que definem os relacionamentos entre eles.

Existem vários tipos de relacionamentos entre bounded contexts, cada um com características específicas. O partnership ocorre quando dois contextos têm dependência mútua e as equipes precisam colaborar de forma coordenada para alinhar suas necessidades. É uma relação de parceria onde ambos os lados precisam evoluir juntos, pois mudanças em um afetam o outro diretamente.

Para entender melhor, vamos comparar os principais tipos de relacionamento:

No caso da questão, o enunciado afirma que "o bounded context Patrimonial dependia do bounded context Financeiro e vice-versa" e que "a dependência mútua exigiu que as equipes dos contexts Patrimonial e Financeiro interagissem entre si, a fim de alinhar as necessidades de um context em relação ao outro". Essa descrição é a definição clássica de partnership: dois contextos que dependem um do outro e cujas equipes precisam trabalhar em parceria para alinhar suas necessidades.

A pegadinha da questão está em confundir partnership com shared kernel. No shared kernel, há um compartilhamento de código/modelo entre os contextos, o que não é mencionado no enunciado. No partnership, não há compartilhamento de modelo, mas sim uma colaboração entre as equipes para coordenar as mudanças.

Alternativa A — ❌ Incorreta

O conformist ocorre quando um contexto downstream simplesmente segue o modelo do contexto upstream, sem tentar adaptá-lo ou questioná-lo. Não há dependência mútua, mas sim uma relação unilateral onde o downstream se conforma ao upstream. No caso da questão, há dependência mútua, o que descarta essa alternativa.

Alternativa B — ✅ Correta ⟵ GABARITO

O partnership é exatamente o relacionamento descrito no enunciado: dois bounded contexts com dependência mútua, onde as equipes precisam colaborar e coordenar suas necessidades. A parceria é necessária porque mudanças em um contexto impactam o outro, exigindo alinhamento contínuo entre as equipes.

Alternativa C — ❌ Incorreta

O shared kernel envolve o compartilhamento de um subconjunto do modelo de domínio entre dois ou mais contextos. As equipes compartilham código e modelo, o que exige um alto nível de integração. No enunciado, não há menção a compartilhamento de modelo, apenas a dependência mútua e interação entre equipes, o que caracteriza partnership, não shared kernel.

Alternativa D — ❌ Incorreta

A anti-corruption layer é uma camada de proteção que isola um contexto downstream das mudanças do contexto upstream, traduzindo o modelo do upstream para o modelo do downstream. É usada quando se quer proteger um contexto das influências de outro, não quando há dependência mútua e colaboração entre equipes.

Alternativa E — ❌ Incorreta

O customer and supplier (cliente e fornecedor) é uma relação onde um contexto é o cliente (downstream) e o outro é o fornecedor (upstream). O fornecedor define o contrato e o cliente o consome. Não há dependência mútua, mas sim uma relação hierárquica, o que não se aplica ao caso da questão.

Gabarito: letra B