Questão de Engenharia de Software — DDD (Domain-Driven Design) — CESPE / CEBRASPE 2025

DDD: Anti-Corruption Layer (ACL) e comunicação entre bounded contexts

Gabarito: Errado (E). O ACL (anti-corruption layer) é, de fato, um mecanismo de tradução entre bounded contexts, mas a afirmativa erra ao impor que sua implementação exige comunicação assíncrona e que seria inviável em sistemas síncronos. O ACL é um padrão de design que pode ser aplicado tanto em integrações síncronas quanto assíncronas — a escolha do estilo de comunicação é uma decisão arquitetural independente da necessidade de tradução.

O Domain-Driven Design (DDD) é uma abordagem de desenvolvimento de software que centra o projeto em um modelo de domínio rico, refletindo os processos e regras de negócio. Seus três pilares são a linguagem ubíqua, os bounded contexts (contextos delimitados) e os context maps (mapas de contexto). Os bounded contexts delimitam cada modelo de domínio, e os context maps descrevem como esses contextos se relacionam. Quando dois bounded contexts precisam se comunicar, mas possuem modelos de domínio diferentes, surge a necessidade de traduzir conceitos entre eles — é exatamente aí que entra o ACL.

O Anti-Corruption Layer é um padrão de design que atua como uma barreira de proteção entre dois bounded contexts, isolando o modelo de domínio de um contexto das influências do modelo de outro. Ele traduz as informações de um modelo para o outro, evitando que o modelo de um contexto seja "corrompido" por conceitos estranhos do outro. Essa tradução pode ser implementada de diversas formas: por meio de serviços, adaptadores, fachadas ou até mesmo eventos. A comunicação entre os contextos pode ser síncrona (como chamadas HTTP/REST) ou assíncrona (como mensageria), dependendo dos requisitos de negócio e das decisões arquiteturais. Não há nenhuma restrição no padrão ACL que exija assincronia.

Na prática, imagine dois bounded contexts: o de "Vendas" e o de "Estoque". O contexto de Vendas pode ter um modelo de "Produto" com atributos como preço e descrição, enquanto o de Estoque pode ter um modelo de "Item" com atributos como quantidade e localização. Quando Vendas precisa consultar a disponibilidade de um produto, o ACL traduz a solicitação do modelo de Vendas para o modelo de Estoque e vice-versa. Essa tradução pode ser feita por uma chamada síncrona (o serviço de Vendas chama o serviço de Estoque e aguarda a resposta) ou por um evento assíncrono (Vendas publica um evento "ProdutoConsultado" e Estoque responde com outro evento). Ambas as abordagens são válidas e o ACL funciona em ambas.

A pegadinha da banca está em associar o ACL a uma exigência de comunicação assíncrona. Isso é um erro conceitual: o ACL é um padrão de tradução, não um padrão de comunicação. A escolha entre síncrono e assíncrono é uma decisão de arquitetura de integração, que pode ser tomada independentemente da necessidade de tradução. Portanto, a afirmativa está incorreta ao afirmar que o uso do ACL é inviabilizado em sistemas síncronos.

Guarde essa distinção: o ACL resolve o problema de tradução de modelos; a comunicação síncrona ou assíncrona resolve o problema de como os contextos trocam mensagens. São decisões ortogonais.

Item — ❌ Errado

A afirmativa contém dois erros: (1) afirma que o ACL exige comunicação assíncrona, o que não é verdade — o ACL pode ser implementado tanto com comunicação síncrona quanto assíncrona; (2) afirma que o uso do ACL é inviabilizado em sistemas síncronos, o que também é falso. O ACL é um padrão de tradução de modelos entre bounded contexts, e a comunicação pode ser síncrona (ex.: chamadas REST) ou assíncrona (ex.: mensageria), dependendo dos requisitos. Não há nenhuma restrição no padrão que exija assincronia.

Gabarito: Errado (E).