Como você define limites de serviço usando DDD bounded contexts?

Question

Accepted Answer

Bons limites de serviço seguem **capacidades de negócio**, não camadas técnicas. **Domain-Driven Design (DDD)** oferece uma ferramenta precisa para isso: o **bounded context** — um limite dentro do qual um modelo de domínio e seus termos são consistentes.

## Bounded context

A palavra "Customer" pode significar coisas diferentes em contextos diferentes. Cada bounded context possui seu próprio modelo, e um microsserviço normalmente mapeia para um contexto.

```text
┌───────────────────┐   ┌────────────────────┐
│  Sales context    │   │  Support context   │
│  Customer =       │   │  Customer =        │
│   leads, orders   │   │   tickets, SLAs    │
└───────────────────┘   └────────────────────┘
   one service             another service
```

## Como encontrar limites

- **Alinhe-se com capacidades de negócio** (Orders, Billing, Shipping), não substantivos ou tabelas de banco de dados.
- **Alta coesão dentro, acoplamento fraco entre** o limite.
- Observe onde a **ubiquitous language** muda — geralmente é uma borda de contexto.
- Use um **context map** para documentar relacionamentos (upstream/downstream).

## Anti-padrões

```text
✗ Entity services ("User service", "Product service") — too fine, chatty
✗ Splitting by technical layer (a "database service")
✗ Boundaries that force a distributed transaction for every operation
```

Se dois serviços constantemente se chamam para concluir uma operação, o limite provavelmente está errado.

## Por que isso importa

Limites decididos cedo são muito caros para serem movidos depois, porque se endurecem em APIs e bancos de dados que outras equipes dependem.

DDD bounded contexts lhe dão uma forma principiada de traçar essas linhas ao longo do negócio, para que os serviços permaneçam coesos e possam evoluir independentemente em vez de constantemente se coordenarem.