Seu monólito funciona. Por enquanto. Mas os bugs surgem a cada nova funcionalidade. O time evita mexer em certas partes. O deploy demora horas. Você sabe que precisa migrar para microsserviços – mas o maior medo é criar uma “big ball of mud” distribuída, só que agora na rede.
O erro mais comum é começar a quebrar o monólito por critérios técnicos (separar API de banco, separar frontend do backend). Isso quase sempre falha. O segredo está em extrair por domínios de negócio – e a melhor ferramenta para isso é o Domain-Driven Design (DDD).
Neste post, vamos mostrar como a Jacobus Software aplica DDD para identificar bounded contexts, extrair domínios coesos e transformá-los em microsserviços em Go – sem criar um pesadelo distribuído.
Por que quebrar por tecnologia não funciona
Muitas empresas tentam: “vamos tirar o módulo de usuários do monólito e virar um microsserviço”. Mas o módulo de usuários conversa com o módulo de pedidos, que conversa com o de pagamentos. No fim, você só movimentou o acoplamento – antes era dentro do mesmo processo, agora virou chamada de rede.
A solução é extrair domínios coesos, que tenham sentido de negócio e poucas dependências com o resto.
Domain-Driven Design em 2 minutos (para engenheiros)
DDD não é complicado. Os conceitos essenciais para extração são:
| Conceito | O que significa | Exemplo (e-commerce) |
|---|---|---|
| Domínio | O problema de negócio como um todo | E-commerce |
| Subdomínio | Uma parte do negócio | Pagamentos, Estoque, Entrega, Notificações |
| Bounded Context | O limite dentro do qual um termo tem significado único | “Cliente” no contexto de CRM tem endereço; no contexto de Pagamentos tem cartão de crédito |
| Aggregate | Um grupo de objetos que deve ser consistente | Pedido + Itens do pedido (não pode haver item sem pedido) |
Regra de ouro para extração: Cada bounded context pode se tornar um microsserviço. Se dois bounded contexts precisam conversar, eles se comunicam via APIs bem definidas ou eventos.
Estratégia de extração em 5 passos com Go
Passo 1: Mapeie os bounded contexts do monólito
Analise o código e as conversas com o negócio. Identifique fronteiras naturais. Exemplo de um monólito de e-commerce:
- Contexto de Catálogo (produtos, categorias, preços)
- Contexto de Estoque (quantidades, reservas, entradas)
- Contexto de Pedidos (carrinho, checkout, status)
- Contexto de Pagamentos (transações, cartões, boletos)
- Contexto de Entrega (frete, rastreio)
- Contexto de Notificações (e-mail, SMS, push)
Passo 2: Priorize o primeiro contexto a extrair
Use três critérios:
- Baixo acoplamento com o resto (poucas chamadas de saída)
- Alto valor de negócio (time ganha autonomia)
- Baixo risco (falhas não derrubam o core)
O contexto de Notificações geralmente é o melhor candidato – é isolado por natureza.
Passo 3: Extraia como um microsserviço em Go
Comece criando o novo serviço em Go com:
- Uma API limpa (gRPC ou REST)
- Seu próprio banco de dados (opcional, pode compartilhar temporariamente)
- Eventos publicados para comunicação eventual
// Exemplo: serviço de notificações em Go
type NotificationService interface {
SendEmail(to, subject, body string) error
SendSMS(to, message string) error
}Passo 4: Estrangule a funcionalidade no monólito
Em vez de cortar tudo de uma vez, use feature flags ou um proxy. O monólito ainda pode chamar o novo serviço ou ainda executar localmente – você decide por rota.
Passo 5: Repita
Cada contexto extraído reduz a complexidade do monólito. Em meses, o monólito vira um orquestrador fino, e os domínios reais estão em serviços independentes.
Como Go ajuda (e muito) nesse processo
| Desafio na extração | Por que Go resolve |
|---|---|
| Comunicação entre serviços | gRPC é nativo e performático |
| Eventos e assincronicidade | Canais e clientes de broker maduros |
| Bibliotecas compartilhadas | Módulos Go permitem versionamento limpo |
| Testes de integração | Testcontainers para Go é maduro |
| Performance sem surpresas | Garbage collector previsível, baixa latência |
Além disso, a tipagem forte de Go ajuda a manter os contratos entre bounded contexts sem ambiguidade.
Exemplo real: extração de notificações em Go
Na Jacobus, extraímos o contexto de notificações de um monólito PHP de uma fintech. O processo:
- Mapeamento: Identificamos que notificações tinham apenas entradas (pedido criado, pagamento aprovado) e saídas (e-mail, SMS) – ideal para isolamento.
- Nova service em Go: Desenvolvemos uma API HTTP simples que aceita eventos e envia notificações.
- Adapter no monólito: O monólito passou a publicar mensagens em um tópico Kafka em vez de enviar e-mail diretamente.
- Go consome: O serviço Go consome o Kafka e envia e-mails via AWS SES.
- Resultado: Monólito perdeu 15% de complexidade. Notificações agora escalam independentemente. Picos de black friday: só escalamos o serviço Go, sem tocar no monólito.
Cuidado: anti-padrões comuns ao extrair
❌ Shared database: Dois microsserviços acessando a mesma tabela. Isso recria o acoplamento.
❌ Chatty API: Extrai um contexto mas cada operação exige 10 chamadas entre serviços.
❌ Distributed monolith: Só separou o código, mas mantém deploy acoplado ou transações distribuídas demais.
✅ Solução: Use bancos separados, replique dados via eventos, aceite consistência eventual onde fizer sentido.
Quando NÃO extrair?
Se o monólito é pequeno (menos de 10 devs), ou o time não tem maturidade operacional (Kubernetes, CI/CD, observabilidade), extrair pode trazer mais dor que benefício. Comece melhorando o monólito – modularização interna, testes, CI/CD.
Mas se o monólito já trava o negócio, DDD + Go é o caminho mais seguro.
Conclusão: extraia por domínio, não por tecnologia
Migrar de monólito para microsserviços é uma mudança de paradigma. Se feita por critérios técnicos, você só troca seis por meia-dúzia. Se feita por domínios de negócio com DDD, cada serviço passa a ter uma razão clara para existir, evoluindo no ritmo que o negócio precisa.
Go, com sua simplicidade, performance e ótimo suporte a comunicação entre serviços, é a ferramenta ideal para implementar essa visão. Na Jacobus Software, aplicamos esse método em dezenas de projetos – do legado que travava ao sistema que escala.
Seu monólito não é uma sentença. É um ponto de partida.
🧩 Quer extrair domínios do seu monólito com segurança?
Nossos arquitetos mapeiam seus bounded contexts, priorizam a extração por valor e implementam os microsserviços em Go – sem parar a operação.