DEV Community

Rodrigo Castro
Rodrigo Castro

Posted on

Microserviços Everywhere? Talvez seja hora de conhecer o Monólito Modular

#braziliandevs #laravel #microservices #programming

A arquitetura que combina o melhor dos dois mundos e pode salvar seu próximo projeto

O Hype dos Microserviços

Vivemos em uma era onde falar de microserviços virou quase obrigatório em qualquer conversa sobre arquitetura de software. Netflix fez, Uber fez, então obviamente seu projeto também deveria começar com microserviços, certo?

Spoiler alert: Provavelmente não.

A realidade é que muitas empresas estão criando "microserviços distribuídos monolíticos" - sistemas complexos, difíceis de debuggar e manter, que herdam as desvantagens dos microserviços sem colher os benefícios.

A Síndrome do "Microserviços First"

Vamos ser honestos: quantos projetos você conhece que começaram "fazendo a coisa certa" com microserviços e acabaram assim:

❌ 5 serviços para um MVP que poderia ser uma única aplicação

❌ Transações distribuídas para operações que deveriam ser atômicas

❌ Debugging infernal espalhado por múltiplos logs

❌ Deploy complexo desde o dia 1

❌ Time perdido configurando infraestrutura ao invés de validar produto

"Premature optimization is the root of all evil" - Donald Knuth

Começar com microserviços é otimização prematura de arquitetura.

Por Que NÃO Começar com Microserviços?

1. Você Não É a Netflix (Ainda)

  • Netflix tem milhões de usuários simultâneos
  • Você provavelmente tem dezenas ou centenas
  • Eles têm centenas de desenvolvedores
  • Você tem 2-10 pessoas no time

2. Complexidade Desnecessária 

Monólito: 1 deploy, 1 banco, 1 log
Microserviços: N deploys, N bancos, N logs, N configurações
Enter fullscreen mode Exit fullscreen mode

3. Debugging Nightmare 

Bug no monólito: Stack trace completo
Bug em microserviços: "Qual serviço quebrou? Em que ordem?"
Enter fullscreen mode Exit fullscreen mode

4. Over-engineering do MVP

Você deveria estar validando seu produto, não configurando Kubernetes.

Conheça o Monólito Modular

E se eu te disser que existe uma arquitetura que combina:

✅ Simplicidade do monólito para desenvolver e deployar

✅ Organização dos microserviços para manter e escalar

✅ Flexibilidade para evoluir gradualmente

✅ Performance de transações locais

Essa arquitetura existe e se chama Monólito Modular.

Como Funciona?

Imagine uma aplicação Laravel organizada assim:

app/
├── Domains/
│   ├── User/          # Módulo de usuários
│   ├── Product/       # Módulo de produtos  
│   ├── Order/         # Módulo de pedidos
│   └── Payment/       # Módulo de pagamentos
├── Shared/            # Código compartilhado
└── Infrastructure/    # Concerns técnicos
Enter fullscreen mode Exit fullscreen mode

Características Principais:

🔹 Um único aplicativo - Deploy simples, debugging fácil

🔹 Módulos bem definidos - Separação clara de responsabilidades

🔹 Comunicação via interfaces - Baixo acoplamento

🔹 Banco de dados compartilhado - ACID transactions

🔹 Migração gradual - Evolução para microserviços quando necessário

Vantagens Práticas

Para o Time

  • Onboarding rápido - Nova pessoa entende a estrutura em horas
  • Desenvolvimento ágil - Mudanças rápidas sem coordenação entre times
  • Debugging simples - Stack trace completo, logs centralizados

Para o Negócio

  • Time to market menor - Foco no produto, não na infraestrutura
  • Custos reduzidos - Menos complexidade = menos recursos
  • Validação rápida - Iterar rapidamente sobre features

Para a Arquitetura

  • Testabilidade - Testes integrados simples
  • Consistência - Transações ACID entre módulos
  • Flexibilidade - Migration path claro para microserviços

Quando Evoluir para Microserviços?

O monolito modular oferece um migration path natural:

Fase 1: Monólito modular
├── Validar produto
├── Crescer time
└── Identificar gargalos

Fase 2: Extração gradual
├── Módulo Payment → Microserviço
├── Módulo Notification → Microserviço  
└── Core continua monólito

Fase 3: Microserviços completos
└── Quando realmente justificar
Enter fullscreen mode Exit fullscreen mode

Sinais de que é hora de extrair:

  • Módulo tem problemas de performance específicos
  • Time grande trabalhando no mesmo módulo
  • Escalabilidade diferente entre módulos
  • Tecnologia específica seria melhor para um módulo

Empresas que Usam (e Recomendam)

  • Shopify - Monólito modular gigante que atende milhões
  • GitHub - Rails monólito que escala massivamente
  • Basecamp - Defensores ferrenhos do monólito bem estruturado
  • Laravel (próprio framework) - Monólito modular por design

"The monolith isn't dead. It's just well-designed." - DHH, Basecamp

Implementação Prática

Estrutura de um Módulo: 

app/Domains/Order/
├── Models/           # Entidades do domínio
├── Services/         # Regras de negócio
├── Repositories/     # Acesso a dados
├── Events/           # Eventos do domínio
├── Http/
│   ├── Controllers/  # Controllers REST
│   └── Livewire/     # Componentes TALL
└── Tests/           # Testes do módulo
Enter fullscreen mode Exit fullscreen mode

Comunicação Entre Módulos: 

// Via Service (síncrono)
$this->orderService->createOrder($data);

// Via Events (assíncrono) 
OrderCreated::dispatch($order);
Enter fullscreen mode Exit fullscreen mode

Conclusão: Comece Simples, Escale Gradualmente

A pergunta não é: "Microserviços ou Monólito?"

A pergunta é: "Qual arquitetura me permite validar meu produto mais rápido?"

O monólito modular oferece:

  • Simplicidade para começar
  • Estrutura para crescer
  • Flexibilidade para evoluir

Seu próximo projeto provavelmente deveria começar como um monólito modular.

Depois, quando você tiver:

  • ✅ Produto validado
  • ✅ Time maior
  • ✅ Problemas reais de escala

Aí sim considere microserviços.

E você, já experimentou o monólito modular? Compartilhe sua experiência nos comentários! 👇

Top comments (0)