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:
- A)conformist;
Errada, porque conformist ocorre quando um bounded context aceita o modelo do outro sem impor sua própria visão.
- B)partnership;
Certa, porque partnership é o tipo de relação em que há dependência mútua e forte coordenação entre os bounded contexts.
- C)shared kernel;
Errada, porque shared kernel pressupõe o compartilhamento de uma pequena parte comum do modelo, não uma parceria ampla e contínua.
- D)anti-corruption layer;
Errada, porque anti-corruption layer é uma estratégia de proteção contra influência externa, e não uma relação de dependência recíproca.
- E)ccustomer and supplier.
Errada, porque customer and supplier indica uma relação assimétrica entre quem demanda e quem fornece, não uma parceria com dependência mútua equilibrada.
Gabarito: B
No Domain-Driven Design (DDD), os bounded contexts existem para que cada parte do sistema tenha seu modelo e suas regras bem definidos, sem virar uma salada de conceitos. Quando dois contexts dependem fortemente um do outro e precisam conversar de forma constante para alinhar necessidades, isso indica uma relação de cooperação intensa entre equipes, não de isolamento. Em outras palavras, os times não conseguem trabalhar bem se cada um puxar para um lado diferente. Esse cenário descreve o relacionamento de partnership. Aqui, os dois bounded contexts têm interdependência relevante e precisam de coordenação frequente para evoluir juntos. A ideia é que as equipes atuem como parceiras, com decisões alinhadas, porque mudanças em um context impactam diretamente o outro. Por isso, a banca quer enxergar a noção de dependência mútua com colaboração estreita. As demais alternativas apontam para outros tipos de integração. Conformist é quando um context simplesmente aceita o modelo do outro, sem muita negociação. Shared kernel envolve compartilhar uma parte pequena e comum do modelo. Anti-corruption layer é uma camada de proteção para evitar que o modelo externo contamine o interno. Customer and supplier aparece quando um lado depende do outro em uma relação mais assimétrica, e não exatamente de parceria entre iguais. Assim, como o enunciado fala em dependência mútua e necessidade de interação entre as equipes para alinhar as necessidades de ambos os contexts, o gabarito correto é partnership.