Strategic DDD
Bounded contexts, ubiquitous language, context mapping — o desenho ANTES do código
DDD estratégico é sobre fronteiras, não classes. Onde termina um modelo? Como times falam entre si? Onde vale a pena investir? Decidir isso errado custa anos — refatorar código é fácil; redesenhar fronteiras depois que 50 microserviços já existem, não.
Os três tipos de subdomínio
Antes de decidir como construir, decida onde investir. Subdomínio é uma área de negócio. Cada um merece uma estratégia diferente.
| Tipo | O que é | Estratégia | Exemplo (pagamentos) |
|---|---|---|---|
| Core | O que diferencia seu negócio. Onde a vantagem competitiva mora. | Build. Time sênior, código limpo, modelo rico, DDD tático completo. | Motor de roteamento de pagamentos, anti-fraude proprietário |
| Supporting | Necessário, mas não é o diferencial. Apoia o core. | Build simples ou custom. CRUD pode bastar; design defensivo no boundary com core. | Conciliação contábil, gestão de comerciantes |
| Generic | Resolvido pelo mercado. Comprar é mais barato que construir. | Buy / SaaS. Stripe Identity, Auth0, SendGrid. Não reinvente. | Autenticação, envio de email, geração de PDF |
Erro clássico: tratar tudo como core. Time gasta 6 meses construindo um sistema de e-mail "porque é importante" — e o competidor já está iterando no produto. Importante ≠ core. Core é o que seu cliente paga você para fazer melhor que ninguém.
Como identificar seu core
- Onde o time de produto investe tempo? Se os PMs vivem discutindo essa parte, é core.
- O que você faria diferente do concorrente? Se a resposta é "nada", não é core.
- Quem mexe nesse código? Se é o time mais sênior, é core. Se é qualquer estagiário, é supporting/generic.
- Mudaria a estratégia se isso quebrasse? Se sim, core.
Por que mapear subdomínios antes de microservices?
Microservice mal cortado é dívida arquitetural. Se você fatia em service-por-tabela, vai gastar o dobro coordenando deploys e queries distribuídas, sem ganho de autonomia. Subdomínio define a granularidade natural do negócio — um service por subdomínio (ou por bounded context dentro do subdomínio) tende a se manter coeso. Sem essa lente, o sistema vira "distributed monolith".