Microsserviços: e se o problema for justamente o ‘micro’?
A parte mais difícil dos microsserviços não é a tecnologia — são os limites.
Qual é o tamanho certo para um microsserviço? Será que ele deve ser tão pequeno que toda a sua lógica caiba na nossa cabeça?
Se você já se viu debatendo isso em reuniões, sabe como a discussão pode ficar acalorada. Uns defendem que “quanto menor, melhor”, enquanto outros argumentam que, ao exagerar na granularidade, criamos uma sopa de serviços difíceis de gerenciar. E, cá entre nós, ambas as posições têm seus pontos fortes. É justamente esse equilíbrio que torna o assunto tão pertinente.
Neste artigo, vamos conversar sobre isso. Vamos explorar de onde vem essa ideia de “caber na cabeça” e o que realmente significa na prática.
A ideia aqui é refletir junto com você. Não tem resposta certa ou fórmula mágica, mas há boas práticas, experiências compartilhadas e conceitos importantes para considerar.
Dá onde nasceu essa expressão “caber na sua cabeça”?
Essa frase — “caber na sua cabeça” — tem algo de curioso, quase provocativo. Afinal, estamos falando de software, não de objetos físicos tentando se espremer dentro de um espaço limitado. Ainda assim, essa metáfora pegou: a ideia de que um microsserviço deveria ser simples o bastante para que qualquer desenvolvedor consiga entendê-lo por completo, sem precisar virar detetive.
A expressão nasceu como reação aos antigos sistemas monolíticos — aqueles monstrões gigantes que só meia dúzia de pessoas sabiam como funcionavam. E mesmo assim, às vezes, nem essas pessoas tinham certeza. O resultado? Bugs difíceis de rastrear, deploys arriscados, retrabalho entre times e aquele clássico medo coletivo de “mexer onde não se deve”.
Quando os microsserviços começaram a ganhar espaço, veio também a promessa de mais clareza, mais autonomia e menos dor de cabeça. Cada serviço deveria ser enxuto, focado e compreensível. Em outras palavras: deveria caber na sua cabeça.
Mas… será que essa ideia é só sobre tamanho?
Ou estamos confundindo simplicidade com superficialidade?
Afinal, o que exatamente significa “micro” em microsserviços?
Será que estamos medindo do jeito certo?
O que é “micro” em microsserviços?
Antes de discutir arquitetura, vale a pena voltar ao básico: o significado das palavras.
Micro 🔬 vem do grego mikrós, que significa “pequeno” ou “minúsculo”. No dicionário, costuma remeter a algo de dimensão reduzida ou de escopo restrito. Não significa “insignificante”, e muito menos “simplório”. Micro carrega a ideia de compacidade com propósito — algo pequeno, mas que possui uma função clara e delimitada.
Serviço ⚒️, por sua vez, vem do latim servitium, e no contexto de software representa uma funcionalidade disponibilizada para uso por outro módulo ou sistema. Ou seja, um serviço é algo que entrega valor, atende a uma demanda, ou resolve um problema de forma bem definida.
Quando juntamos as duas palavras, formamos o conceito de microsserviço — um serviço pequeno, mas não no tamanho do código, e sim no escopo da responsabilidade. Ele é “micro” porque:
tem um foco específico dentro de um domínio de negócio;
é autônomo o suficiente para evoluir e ser implantado de forma independente;
não depende excessivamente de outros serviços para entregar seu valor.
Mas cuidado: "micro" não significa que o serviço tem poucas linhas de código, poucas regras, ou que deve ser artificialmente dividido. O que importa é o foco, a coesão e a clareza de propósito.
Um microsserviço pode encapsular regras complexas – como validações antifraude, fluxos de pagamento ou cálculos tributários – desde que tudo isso faça parte de uma mesma responsabilidade coesa.
Por isso, entender bem o que é “micro” e o que é “serviço” ajuda a evitar erros comuns, como fatiar demais um sistema ou criar serviços anêmicos que dependem de meio mundo para funcionar. Microsserviços não são sobre “pequenes”, mas sobre clareza de fronteiras e independência funcional.
Lembre-se disso:
“Micro” define o escopo. “Serviço” define a entrega de valor. E um bom microsserviço é aquele que une esses dois conceitos com propósito.
Então, “caber na sua cabeça” é sobre o quê, exatamente?
Spoiler: não é sobre quantidade de linhas de código. Nem sobre quantas classes ou arquivos existem no projeto.
“Caber na cabeça” é sobre complexidade cognitiva, ou seja, o esforço mental necessário para entender o que aquele serviço faz — e por quê ele existe. É sobre clareza, propósito e previsibilidade. Um bom microsserviço se explica sozinho, ou pelo menos não exige um mestrado em “contexto do sistema inteiro” para ser entendido.
Pensa comigo: você precisa entender como funciona a engenharia de uma cafeteira elétrica pra conseguir fazer café? Não. Basta saber qual botão apertar.
Da mesma forma, um microsserviço bem projetado tem uma função clara. Ele expõe um contrato compreensível, e quem interage com ele não deveria precisar abrir 10 abas no GitHub pra descobrir o que vai acontecer quando chamar aquele endpoint.
Agora vem o pulo do gato:
Simplicidade cognitiva não é o mesmo que código pequeno.
Você pode ter um serviço com 300 linhas e ainda assim deixar todo mundo perdido. E pode ter um serviço com mil linhas e várias regras — mas se tudo estiver bem dividido, nomeado, testado e alinhado com o domínio, ele vai parecer pequeno para a mente. E é isso que importa.
O problema não é a complexidade em si, mas o descontrole sobre ela.
Outro ponto importante. Às vezes, na obsessão por tornar tudo “micro”, caímos numa armadilha: fatiamos demais, criamos serviços frágeis, altamente acoplados, com regras espalhadas e difícil rastreabilidade. E aí, ironicamente, o que deveria “caber na cabeça” começa a explodir nossa cabeça.
Tá mas ainda temos outras questões que precisamos mergulhar, continua comigo!
Como encontrar o equilíbrio?
Quando falamos em microsserviços, uma dúvida inevitável aparece: qual o tamanho certo de um serviço? E, talvez mais importante, como saber se estamos exagerando na fragmentação ou centralizando demais?
A resposta, embora simples na teoria, é complexa na prática: o equilíbrio está no domínio.
Em vez de medir um microsserviço pelo número de linhas de código ou pela quantidade de endpoints, o critério mais valioso é o alinhamento com um contexto de negócio claro e bem definido. O serviço precisa ser coeso — todas as suas funcionalidades devem servir a um propósito único e reconhecível dentro do domínio.
Isso quer dizer que um microsserviço pode, sim, ser “grande” em termos de regras ou escopo técnico, desde que ele resolva bem um único problema de negócio com clareza e autonomia.
Chris Richardson, em Microservices Patterns, reforça essa visão ao dizer que:
“O tamanho ideal de um microsserviço não é determinado por linhas de código, mas pela clareza com que ele resolve um problema e sua capacidade de evoluir de forma independente.”
Vamos a um exemplo mais concreto.
Imagine um sistema para uma clínica médica. Um dos contextos de negócio pode ser gerenciamento de agendamentos. Faz sentido agrupar nessa responsabilidade todas as ações relacionadas: marcar consultas, verificar a disponibilidade de médicos, alterar horários, cancelar compromissos e enviar notificações.
Esse microsserviço pode ter centenas de linhas de lógica, diferentes fluxos e integrações. Mas ele continua coeso, porque tudo gira em torno do mesmo eixo: agendamentos. Ele tem clareza de propósito, autonomia para evoluir, e um limite de fronteira bem definido.
Agora, pense no que poderia acontecer se tentássemos ser “mais micro do que o necessário”: criamos um serviço só para verificar a agenda do médico, outro para cancelar consultas, outro só para mandar notificações. O que parecia modularidade vira um emaranhado de serviços conversando entre si para executar uma tarefa simples — o famoso distributed monolith. A complexidade da orquestração cresce, o número de falhas potenciais aumenta, e cada alteração no fluxo de agendamento exige uma coordenação entre múltiplas equipes e serviços.
O resultado? Mais pontos de falha. Mais latência. Mais testes end-to-end para garantir que tudo funciona junto. Menos produtividade. Menos clareza. Maior carga cognitiva.
Chris Richardson também alerta sobre isso: excesso de fragmentação compromete a autonomia dos serviços e transforma a manutenção em um pesadelo. Ele defende que, em vez de buscar um "micro" absoluto, devemos mirar em serviços com responsabilidade única, mas que sejam autossuficientes dentro do seu domínio.
Em outras palavras: pequeno o suficiente para ser compreendido, grande o suficiente para ser útil.
Encontrar esse equilíbrio exige mais do que seguir um padrão técnico. É preciso entender profundamente o domínio, conversar com o negócio, mapear fluxos reais e aplicar o bom senso arquitetural. Fragmentar sem propósito é como cortar um quebra-cabeça em peças tão pequenas que ninguém mais consegue montar.
No final, microsserviços não são sobre tamanho, mas sobre responsabilidade, independência e clareza.
E talvez, só talvez, o que “cabe na cabeça” de verdade... seja o domínio, e não o código.
Complexidade no lugar certo
Nem toda complexidade é ruim. Em sistemas reais, ela é inevitável. Mas há uma diferença crucial entre complexidade necessária e complexidade espalhada.
Um dos princípios fundamentais na arquitetura de microsserviços é:
“A complexidade deve estar concentrada, não distribuída.”
Pense em um serviço de faturamento. Ele precisa lidar com múltiplas regras tributárias, diferentes alíquotas por estado, lógica de desconto por perfil de cliente, emissão de notas fiscais e integrações com sistemas externos. Sim, é um serviço complexo — mas é uma complexidade densa e localizada.
Sua responsabilidade está clara: faturar pedidos. Toda a lógica gira em torno disso. O serviço é difícil, mas é compreensível, testável e o mais importante, coeso.
Agora imagine o cenário oposto.
Você decide “quebrar” esse serviço para torná-lo mais “micro”: cria um serviço só para cálculos de imposto, outro só para descontos, outro para enviar notas fiscais, outro para integração com gateways. De repente, o que era difícil, mas localizado, virou um emaranhado de serviços interdependentes.
Resultado? 💥Cada vez que você fatura um pedido, precisa orquestrar chamadas em cadeia, tratar falhas em cascata, sincronizar estados entre múltiplos contextos. A complexidade que antes era concentrada agora está espalhada pelo sistema — e isso é a receita perfeita para o caos.
Esse fenômeno tem nome: monólito distribuído.
Você perde a simplicidade do monólito sem conquistar os benefícios reais dos microsserviços. E quando isso acontece, ninguém ganha. Nem o negócio, nem a arquitetura, nem a equipe de desenvolvimento.
O tamanho é relativo ao problema
Quando falamos em “tamanho ideal”, a pergunta não é:
“Quantas linhas de código ele tem?”
Mas sim:
“Esse serviço resolve um problema de negócio de forma clara, autônoma e coesa?”
Não existe um tamanho absoluto que determine se um microsserviço está “certo” ou “errado”. O que importa é a proporção entre a responsabilidade que ele assume e o escopo do domínio que ele cobre.
Um microsserviço pode ser “grande” — e ainda assim ser enxuto em propósito.
Veja o exemplo de um serviço de inventário. Ele pode lidar com regras sofisticadas: controle de movimentações, ajustes de estoque, sincronização com canais de venda, previsões de demanda com base em histórico. Complexo? Sem dúvida. Mas o foco está ali: inventário. Ele não tenta calcular preços, validar pagamentos ou notificar clientes. Ele conhece seus limites — e por isso, continua coeso, testável e confiável.
O ponto central é esse:
Microsserviços não devem ser pequenos por padrão. Devem ser delimitados com inteligência.
A obsessão por tornar tudo pequeno pode destruir a clareza arquitetural. A obsessão por centralizar tudo pode sufocar a evolução independente dos domínios. O que buscamos não é o menor serviço possível, mas o serviço mais coeso e autônomo possível.
No fim das contas, a pergunta não é “esse serviço é pequeno?”, mas sim:
“Ele é compreensível? Independente? Fiel ao seu domínio?”
Se a resposta for sim, então talvez você já tenha encontrado o equilíbrio certo.
Tamanho e Coesão Andam Juntos
O que define um bom microsserviço? Seu tamanho ou sua coesão?
Essa é uma pergunta que parece simples, mas carrega um dilema arquitetural que muitos times enfrentam na prática.
💡 Quando começamos a desenhar microsserviços, é comum a preocupação inicial ser: “Esse serviço está pequeno o suficiente?” — como se houvesse um limite de linhas de código que, ao ser ultrapassado, transformasse o serviço em algo “errado”.
Mas, como nos mostra Sam Newman, autor de Building Microservices, o critério mais importante não está na dimensão técnica, mas no alinhamento com o propósito de negócio. Vamos explorar mais isso. 👀
O que é coesão, afinal?
Coesão é a proximidade funcional entre as partes de um sistema. É quando tudo que está dentro do microsserviço faz sentido junto, muda junto, e existe para atingir o mesmo objetivo de negócio.
👉 Em outras palavras: um serviço é coeso quando suas funcionalidades compartilham um mesmo ciclo de vida, contexto e responsabilidade.
E o tamanho?
Tamanho, nesse contexto, não deve ser medido em linhas de código, número de classes ou endpoints. O tamanho relevante aqui é o tamanho do problema de negócio que o serviço resolve. Um serviço pode parecer “grande” tecnicamente, mas ainda assim ser “micro” em termos de escopo e responsabilidade, desde que tenha foco.
Coesão e Tamanho: uma dupla inseparável
Esses dois conceitos não competem — eles se complementam.
Um serviço coeso pode ser maior em escopo, porque todas as suas partes estão conectadas, seguem a mesma lógica de domínio e evoluem juntas. Já um serviço pequeno, mas que tenta lidar com responsabilidades desconexas — como autenticação, notificações e pagamentos — rapidamente se torna um problema, mesmo que “caiba na cabeça”.
Tamanho, sem coesão, é apenas fragmentação.
Sam Newman alerta que separar demais os serviços apenas para mantê-los pequenos pode gerar o efeito oposto ao desejado: em vez de modularidade, você cria um sistema onde funcionalidades triviais são pulverizadas em dezenas de serviços. Isso aumenta:
a latência,
a complexidade operacional,
o acoplamento por comunicação,
a dificuldade de entender o sistema como um todo.
É o famoso caso onde o sistema vira uma colcha de retalhos distribuída… difícil de manter, testar, evoluir.
O bom microsserviço é aquele que tem o tamanho da sua coesão
Se todas essas funcionalidades resolvem o mesmo problema de negócio, o serviço está no caminho certo.
Ele pode ser grande na complexidade do domínio, mas micro na sua intenção. Precisa estar focado em um único objetivo de negócio, sem tentar resolver problemas que pertencem a outros contextos.
Por isso, o segredo está aqui:
O foco deve ser na coesão. Quando os limites de negócio estiverem bem definidos, o tamanho do serviço será apenas um reflexo disso.
Vou tentar resumir caro leitor1:
Tamanho sem coesão é fragmentação.2
Coesão com clareza de propósito permite tamanho sustentável.
E o melhor microsserviço é aquele que resolve um problema de negócio — de ponta a ponta — sem sair do seu lugar.
🌱 Quando você entende isso, para de contar linhas e começa a contar valor.
Como identificar e respeitar os limites do negócio?
Depois de entender o equilíbrio entre tamanho e complexidade, surge uma pergunta ainda mais fundamental:
Como saber onde termina um microsserviço e onde começa o outro?
Essa dúvida é especialmente crítica quando estamos migrando de um monolito — onde tudo está misturado — para uma arquitetura baseada em serviços menores e independentes.
E é exatamente aqui que entra uma das contribuições mais valiosas do Domain-Driven Design (DDD), de Eric Evans: o conceito de Bounded Contexts (ou contextos delimitados).
Segundo Sam Newman, os Bounded Contexts são os guias naturais para encontrar os limites de microsserviços. Em Monolith to Microservices, ele afirma:
“Contextos delimitados são um ótimo ponto de partida para identificar limites de serviço.”
Ou seja, ao invés de tentar adivinhar onde cortar, seguimos os limites que o próprio domínio de negócio nos apresenta.
O que é um Bounded Context?
Em um sistema monolítico, é comum ver funcionalidades entrelaçadas, termos ambíguos e regras de negócio espalhadas. O termo “pedido”, por exemplo, pode significar uma coisa em vendas e outra totalmente diferente em logística.
➡️ É justamente para lidar com essa ambiguidade que os Bounded Contexts existem.
Eles definem limites claros, dentro dos quais os conceitos têm um significado consistente, e as regras de negócio estão bem definidas. Fora desses limites, os termos podem — e devem — ter significados diferentes, conforme o contexto.
Cada contexto tem autonomia para modelar o mundo da sua forma, sem depender de como os outros enxergam o mesmo conceito.
Exemplo prático: o "pedido" em diferentes contextos
Imagine um sistema de e-commerce:
No contexto de vendas, um pedido está sendo criado, validado com o estoque, processado com descontos e formas de pagamento.
No contexto de entrega, o mesmo pedido já é tratado como uma lista de itens, com dados de endereço, prazos e transportadora.
São dois contextos legítimos, com regras, objetivos e até estruturas de dados distintas.
Segundo Newman:
“Tentar modelar tudo em um único serviço geralmente leva à confusão, esforço duplicado e muita lógica condicional.”
Ou seja: tentar encaixar tudo num único serviço é abrir as portas para o caos. O código fica cheio de ifs, acoplamento cresce, e o entendimento da lógica vira um jogo de adivinhação.
Bounded Contexts como base da arquitetura
Ao respeitar os Bounded Contexts, conseguimos criar microsserviços que:
🧠 Têm clareza de propósito
🔐 Ocultam sua complexidade interna (information hiding)
🔄 Evoluem de forma independente
📈 Refletem a estrutura do negócio — e não apenas decisões técnicas
E é aqui que entra um dos princípios mais importantes, e frequentemente negligenciados: o ocultamento de informações.
Sam Newman explica:
“Uma parte fundamental da autonomia dos microsserviços é a ocultação de informações — a capacidade de alterar detalhes de implementação interna sem prejudicar os consumidores.”
Em outras palavras: cada serviço deve esconder sua complexidade interna atrás de uma interface clara, revelando apenas o que os outros precisam saber.
Isso é essencial por dois motivos:
Reduz o acoplamento entre serviços – mudanças internas não precisam se propagar para o sistema inteiro.
Aumenta a autonomia das equipes – cada time pode evoluir seu serviço sem medo de quebrar outras partes do sistema.
É como dizer: “Aqui dentro eu resolvo do meu jeito — você só precisa saber como conversar comigo.”
Como aplicar isso na prática?
Converse com o negócio. Entenda como os termos são usados em cada área.
Identifique mudanças de significado. Sempre que um conceito tiver regras ou objetivos diferentes em partes do sistema, é sinal de que você está cruzando um contexto.
Modele os serviços com base nesses limites. Não force um conceito único onde claramente existem dois.
Oculte detalhes internos. Exponha apenas contratos bem definidos, mantendo lógica interna encapsulada.
Evite dependências desnecessárias. Quanto menos um serviço souber sobre os outros, mais saudável será a arquitetura.
Então para resumir…
Coesão vem de respeitar o contexto.
Tamanho certo vem do domínio certo.
Ocultamento de informações mantém sua arquitetura flexível e saudável.
“Bons limites de microsserviços são informados pelos limites de negócios.” — Sam Newman
“A ocultação de informações é o que possibilita a mudança” — Monolith to Microservices
A clareza nos limites do domínio evita confusão conceitual, facilita a evolução contínua do sistema e, principalmente, preserva a autonomia de cada serviço sem comprometer o todo.
Se quiser consultar mais tenho um artigo dedicado a ocultação de informações 👇🏼
Agora quero destacar brevemente outro tema.
“Código que muda junto deve permanecer junto”: o que Sam Newman realmente quis dizer
Um outro princípio apresentado por Sam Newman em Building Microservices é:
“Código que muda junto deve permanecer junto.”
Essa frase, apesar de simples, carrega uma orientação poderosa sobre coesão no design de sistemas distribuídos. Ela nos alerta para um erro comum: separar funcionalidades que são fortemente relacionadas — o que, em vez de modularizar, espalha a complexidade.
O que significa “código que muda junto”?
Pensa na hora do banho.
Sempre que você toma banho, você usa o sabonete… e depois precisa da toalha.
Esses dois itens fazem parte da mesma experiência. Um vem logo depois do outro. Eles mudam juntos com o contexto: o banho.
Agora imagina se o sabonete estivesse no banheiro, mas a toalha ficasse no outro quarto.
Toda vez que você fosse tomar banho, teria que sair pingando pela casa pra buscar o que já deveria estar junto. Parece simples — até virar rotina. E o desconforto vira regra.
🎯 Essa é a armadilha de separar código que muda junto.
No software, acontece o mesmo:
Quando partes da lógica de negócio que precisam mudar juntas estão espalhadas por serviços diferentes, qualquer ajuste exige coordenação, testes extras, retrabalho e risco de erro.
Você não está mais só tomando banho. Está organizando uma logística.
Newman resume bem:
"Se duas partes do sistema mudam juntas, é um forte sinal de que elas deveriam estar juntas."
Ou seja: Se sabonete e toalha fazem parte do mesmo banho, mantenha tudo no mesmo ambiente. No código, isso significa: mantenha juntos os módulos que compartilham o mesmo ciclo de mudança.
Ciclo de vida de um pedido
Pense em um sistema de gerenciamento de vendas com as seguintes funcionalidades:
Criar pedidos
Atualizar o status de pedidos
Cancelar pedidos
Essas funcionalidades fazem parte do mesmo ciclo de vida do pedido, e normalmente mudam juntas quando o negócio evolui. Agora imagine que cada uma delas foi implementada como um microsserviço separado.
Isso traria diversos problemas:
🔗 Mais dependências entre serviços: qualquer alteração exigiria coordenação entre vários times e serviços.
⚠️ Maior risco de falhas: a comunicação entre serviços pode falhar, afetando o comportamento geral.
🔄 Complexidade desnecessária: a lógica do ciclo de vida do pedido fica espalhada, dificultando manutenção e testes.
Em vez de trazer clareza e desacoplamento, a separação prejudica a coesão e aumenta o custo de mudança.
Por que manter “código que muda junto” no mesmo lugar?
Esse princípio está diretamente ligado à coesão. Manter funcionalidades relacionadas dentro do mesmo serviço permite:
✅ Facilidade de manutenção: tudo que precisa mudar junto está em um só lugar.
🔒 Menor acoplamento entre serviços: reduz a necessidade de coordenação entre times e integrações frágeis.
🧠 Mais clareza e simplicidade: o sistema é mais fácil de entender, pois as responsabilidades estão agrupadas logicamente.
Evite separações arbitrárias
Newman chama atenção para um risco real: dividir demais o sistema em serviços pequenos, porém interdependentes. Isso leva ao chamado ao que falamos nos tópicos anteriores, um sistema aparentemente modular, mas que exige esforço e coordenação semelhantes (ou até maiores) aos de um monolito tradicional.
Outro exemplo: gerenciamento de estoque
Considere um domínio de estoque com as seguintes responsabilidades:
Atualizar a quantidade disponível
Reservar itens para pedidos
Repor o estoque com novas entradas
Se essas responsabilidades forem divididas em serviços distintos, qualquer alteração nas regras de negócio exigirá mudanças coordenadas entre eles. Pior: qualquer falha na comunicação pode causar inconsistências graves, como itens reservados que nunca foram descontados do estoque.
Nesse caso, o mais sensato é manter essas responsabilidades no mesmo serviço, pois:
Elas fazem parte do mesmo contexto de negócio
Costumam mudar juntas
Compartilham dados e lógica operacional
Então para juntar tudo o que conversamos…
Não separe o que naturalmente evolui junto.
Priorize coesão, não granularidade artificial.
Serviços pequenos, mas interdependentes, podem gerar mais problemas do que soluções.
“Se partes do seu sistema precisam mudar ao mesmo tempo, elas provavelmente deveriam estar no mesmo serviço.” — Sam Newman
Esse princípio simples é um dos pilares para construir sistemas distribuídos que realmente entregam autonomia, clareza e resiliência.
Quando é necessário separar?
Embora o princípio de manter “código que muda junto” no mesmo lugar seja essencial, há casos em que a separação faz sentido:
• Quando as funcionalidades têm ciclos de vida distintos: Por exemplo, o gerenciamento de estoque e o cálculo de impostos fazem parte de contextos diferentes e podem mudar de forma independente.
• Quando a separação reduz o impacto de mudanças: Por exemplo, um subdomínio que muda frequentemente pode ser isolado para que suas alterações não afetem o restante do sistema.
Como aplicar esse princípio na prática
Para garantir que “código que muda junto permaneça junto”, faça as seguintes perguntas ao projetar microsserviços:
1. Essas funcionalidades compartilham os mesmos dados ou regras de negócio?
• Se sim, provavelmente elas devem estar no mesmo serviço.
2. Essas funcionalidades tendem a ser alteradas juntas?
• Funcionalidades que mudam juntas devem ser agrupadas.
3. A separação introduzirá dependências desnecessárias?
• Se sim, reavalie a decisão de separação.
Sam Newman nos ensina que manter “código que muda junto” no mesmo lugar é um princípio importante para criar microsserviços coesos e sustentáveis. A coesão reduz a complexidade, facilita a manutenção e evita o acoplamento excessivo entre serviços.
No final, a chave é sempre focar no domínio e nas necessidades do negócio, garantindo que o design do sistema esteja alinhado aos seus processos naturais.
O que podemos concluir de tudo o que conversamos?
A ideia de que "um microsserviço deve ser pequeno o suficiente para caber na sua cabeça" é útil, mas incompleta.
📌 Sim, o serviço deve ser compreensível.
Mas isso não significa que ele deva ser artificialmente pequeno, com poucas linhas de código ou com regras de negócio espalhadas em pedaços fragmentados.
O que realmente importa é:
Que ele tenha um propósito claro e coeso.
Que resolva um único problema de negócio de ponta a ponta.
Que suas partes mudem juntas e possam evoluir sem depender de outros serviços.
O tamanho ideal de um microsserviço é o tamanho do seu contexto de negócio. Ele deve ser grande o suficiente para ser útil, mas pequeno o suficiente para ser compreendido como uma unidade funcional.
Como diz Newman:
“Os microsserviços devem ser modelados em torno de domínios de negócios, não de camadas técnicas.”
Então, a resposta final talvez seja:
✅ Um microsserviço deve caber na sua cabeça, dentro dos limites do seu domínio — não porque é pequeno, mas porque é coeso, bem delimitado e alinhado com o que o negócio precisa.
Em resumo, o tamanho de um microsserviço deve ser guiado pelo propósito que ele serve. Ele deve resolver um problema de domínio específico e ser independente em termos de regras de negócio. Isso não significa que ele precisa ser pequeno em linhas de código ou em escopo. Ele pode ter o tamanho que for necessário, desde que seja coeso e respeite os limites do domínio.
Quando encontramos esse equilíbrio, criamos sistemas que são mais fáceis de entender, escalar e manter. O tamanho ideal não é uma métrica fixa; é uma decisão baseada no domínio, nas necessidades do negócio e no design do sistema.
Dividir um sistema apenas para deixá-lo "menor" — sem considerar o porquê daquela separação — gera pedaços desconectados, com responsabilidades embaralhadas e dependências artificiais.
O resultado? Mais complexidade, mais chamadas entre serviços, mais bugs difíceis de rastrear. O sistema não virou modular — virou um quebra-cabeça mal montado.