Questão de Arquitetura de Software — Arquitetura de Software — FGV 2023
Arquitetura de Software›Arquitetura de Software
Código
fg071493
Banca
FGV
Órgão
TCE-SP
Ano
2023
Nível
Superior
Cargo
Agente da Fiscalização - TI
A analista Lúcia projetou a aplicação TCEPaulista utilizando a abordagem Domain-Driven Design (DDD). Foi definido que cada bounded context de TCEPaulista fosse implementado por uma equipe distinta. Lúcia constatou que o bounded context Patrimonial dependia do bounded context Financeiro e viceversa. 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.De acordo com o DDD, o relacionamento entre os bounded contexts Patrimonial e Financeiro é do tipo:
Aconformist;
Bpartnership;
Cshared kernel;
Danti-corruption layer;
Eccustomer and supplier.
Revelar gabarito e comentário▾
GabaritoB — partnership;
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”.
Domain-Driven Design - Relacionamento entre Bounded Contexts
Gabarito: letra B. A descrição de dependência mútua e necessidade de alinhamento bilateral entre as equipes caracteriza o padrão Partnership (parceria). No DDD, o Partnership é utilizado quando dois contextos delimitados são interdependentes, exigindo colaboração contínua para evoluir de forma coordenada.
A questão cobra o conhecimento dos padrões de context mapping em DDD. Vamos analisar cada alternativa:
Padrão DDD
Característica Principal
Relação de Dependência
Exige Colaboração entre Equipes?
Partnership (Gabarito)
Colaboração bilateral e coordenação contínua
Mútua (bidirecional)
Sim, intensa e contínua
Conformist
Um contexto adota o modelo do outro sem negociação
Unilateral (um lado se adapta)
Não (um lado apenas segue)
Shared Kernel
Compartilhamento de uma parte do modelo entre contextos
Parcial (área comum gerenciada em conjunto)
Sim, mas apenas na área compartilhada
Anti-Corruption Layer
Camada de tradução para isolar e proteger um contexto
Unilateral (proteção de um lado)
Não (foco em isolamento)
Customer and Supplier
Relação hierárquica: upstream (fornecedor) e downstream (cliente)
Conformist (conformista): um contexto simplesmente adota o modelo de outro, sem negociação. Não há dependência mútua — um lado se adapta ao outro.
Alternativa B — ✅ Correta ⟵ GABARITO
Partnership: ajusta-se perfeitamente à situação descrita: dependência recíproca e interação entre as equipes para alinhar os contextos.
Alternativa C — ❌ Incorreta
Shared Kernel: envolve compartilhar uma parte do modelo entre contextos, mas não implica necessariamente dependência mútua em toda a extensão; há uma área comum gerenciada em conjunto.
Alternativa D — ❌ Incorreta
Anti-Corruption Layer: é uma camada de tradução para isolar um contexto de outro, evitando contaminação. Não requer colaboração, mas sim proteção.
Alternativa E — ❌ Incorreta
Customer and Supplier: relação de um lado upstream (fornecedor) e downstream (cliente), com hierarquia. A dependência não é mútua — o cliente depende do fornecedor, mas o inverso não é verdadeiro.
PEGA ESSA DICA!
Memorize os principais padrões de context mapping do DDD: Partnership (parceria simétrica), Customer/Supplier (fornecedor/cliente), Conformist (conformidade), Shared Kernel (núcleo compartilhado), Anti-Corruption Layer (camada antiepidemia) e Separate Ways (caminhos separados). A palavra-chave para Partnership é colaboração bilateral e dependência mútua.