DDD no mundo real: Como modelar um Hub de Integração de Marketplaces sem enlouquecer

Se você já tentou modelar um e-commerce ou um marketplace do zero, sabe que é difícil. Mas se você já teve que construir um Hub de Integração — aquele sistema que fica no meio do caminho conectando o ERP do lojista a canais como Mercado Livre, Shopee, TikTok Shop e Netshoes —, você sabe o que é o verdadeiro caos.

Na teoria do Domain-Driven Design (DDD), tudo parece muito limpo. Na prática de um Hub, você descobre que cada marketplace tem uma filosofia de vida completamente diferente.

O Mercado Livre trabalha com o conceito de "Anúncio" que pode ter variações. A Shopee tem uma estrutura de categorias ultra-específica que muda toda semana. O TikTok Shop exige dados de live commerce. E a Netshoes foca muito em grades rígidas de moda (tamanho/cor).

Como modelar um domínio onde a sua única constante é a inconsistência dos outros? Como usar DDD para o Hub não virar um emaranhado de if/else e mapeamentos infinitos?

## O Erro Fatal: O Modelo "Canônico" Mutante

Quando começamos a desenhar um Hub, o primeiro instinto (errado) é criar um modelo único e superpoderoso de Produto ou Pedido que tenta abraçar o mundo. Você cria uma classe com todos os campos possíveis de todas as plataformas.

O resultado? Uma classe Produto com 150 atributos, onde metade é nula dependendo de para onde você está enviando. Se a Shopee inventa um campo novo hoje, você precisa alterar o núcleo do seu sistema, correndo o risco de quebrar a integração com a Netshoes. Você violou o princípio mais básico do DDD: proteger o seu domínio.

No DDD para Hubs, a regra de ouro é: O seu domínio não é o produto. O seu domínio é a sincronização.

## Mapeando os Bounded Contexts em um Hub

Para não enlouquecer, você precisa separar o que é seu do que é dos outros. É aqui que o DDD brilha com os conceitos de Bounded Contexts e Anti-Corruption Layer (ACL — Camada Anticorrupção).

Podemos desenhar o Hub dividindo-o em contextos muito claros:

### 1. Contexto de Core/Catálogo (Seu Domínio)

Aqui fica o seu modelo ideal. O seu cliente (o lojista) te envia um produto do ERP dele. Para o seu Hub, um produto tem apenas o essencial: SKU, Nome, Preço, Estoque e Imagens. É um modelo enxuto, estável e que você controla.

### 2. Contextos de Integração (Os Satélites)

Você cria um contexto delimitado para cada marketplace.

• ▸ContextoMercadoLivre
• ▸ContextoShopee
• ▸ContextoTikTokShop

Dentro do contexto da Shopee, existe uma entidade chamada ProdutoShopee. Ela conhece as bizarrices da API da Shopee. Ela sabe o que é um shopee_item_id. O seu produto central não faz a menor ideia do que é isso.

## A Salvação da Pátria: Anti-Corruption Layer (ACL)

Como o seu Contexto Central conversa com o Contexto da Shopee sem se sujar? Através de uma Camada Anticorrupção.

A ACL é quem faz o trabalho sujo de tradução. Ela recebe o seu Produto limpo e o transforma em um payload que a Shopee entende.

[ERP do Lojista]
       │
       ▼
[Seu Core Domain] ──(Produto Central)
       │
       ├─────────────────────────┐
       ▼                         ▼
[ACL Mercado Livre]       [ACL TikTok Shop]
       │                         │
       ▼                         ▼
(API Mercado Livre)       (API TikTok Shop)

Se o TikTok Shop mudar a API amanhã (e eles vão), o impacto fica restrito apenas à ACL do TikTok Shop. Seu Core Domain continua intacto, sem saber de nada, funcionando perfeitamente.

## Gerenciando o Caos com Eventos de Domínio

Em um Hub, o banco de dados relacional tradicional pode virar um gargalo se você tentar fazer tudo de forma síncrona. Se o lojista altera o estoque de um produto no ERP, você não pode fazer um loop dando HTTP PUT em quatro marketplaces ao mesmo tempo durante a requisição. Se a Shopee cair, o fluxo inteiro trava.

O design correto aqui é orientado a eventos:

• ▸O ERP altera o estoque.
• ▸Seu Core Domain processa e dispara um evento: EstoqueAtualizado.
• ▸As ACLs de cada marketplace assinam esse evento de forma assíncrona.
• ▸A fila do Mercado Livre processa em 2 segundos. A fila da Shopee falha (porque a API deles deu rate limit), entra em retry automático e processa 1 minuto depois.

Para o seu Core Domain, o trabalho acabou no momento em que o evento foi lançado. Cada integração resolve seus próprios problemas no seu próprio tempo (Eventual Consistency).

## Conclusão: Quem ganha o jogo?

Modelar um Hub de integração não é sobre criar o modelo de e-commerce perfeito. É sobre construir fronteiras de isolamento eficientes.

Usar DDD nesse cenário te impede de criar um monstro acoplado que quebra a cada atualização de API de terceiro. Quando você entende que o seu negócio é a tradução e a resiliência do dado, e não o dado em si, o código flui, os testes ficam mais fáceis e você consegue dormir em paz no final de semana — mesmo quando o Mercado Livre decide mudar o contrato da API sem avisar ninguém.