Toda plataforma empresarial chega cedo ou tarde ao mesmo momento: é preciso trocar uma peça, e trocá-la implica mexer em tudo. O CRM que já não serve está enredado com o faturamento, o faturamento com o estoque, o estoque com o portal do cliente. O que deveria ser uma decisão de três meses vira uma substituição de plataforma de dois anos. A arquitetura componível existe para que esse momento não volte a chegar.
A resposta curta: componível não significa muitas peças, significa peças substituíveis. Consegue-se definindo costuras onde o negócio realmente muda, conectando-as com contratos estáveis e medindo o acoplamento com evidência operacional, não com diagramas. E existe um momento em que fragmentar é exatamente o contrário do que convém.
O que é de fato a arquitetura componível?
É projetar por capacidades intercambiáveis, não por caixas desenhadas num slide.
A unidade de uma arquitetura componível é a capacidade de negócio empacotada: um componente autocontido que entrega valor de negócio completo e claro por si só, com um contrato explícito para fora. Cotação, faturamento, identidade, catálogo e roteamento são exemplos típicos. O teste não é quantas peças você tem, e sim se você consegue trocar uma sem negociar com as demais.
O mercado está se movendo nessa direção de forma mensurável. A Gartner projeta que até 2026 pelo menos 70% das organizações terão o mandato de adquirir tecnologia de plataforma de experiência digital componível em vez de suítes monolíticas, contra 50% em 2023 [1].
Dados
| Ano | Percentual de organizações |
|---|---|
| 2023 | 50% |
| 2026 (projetado) | 70% |
Componível é o mesmo que microsserviços?
Não, e confundir os dois é o erro mais caro desta conversa.
Microsserviços são uma decisão de implantação. Componível é uma propriedade do projeto. Dá para ter vinte microsserviços que precisam ser implantados juntos porque compartilham banco de dados, e isso não é componível: é um monolito distribuído com fatura de nuvem. E dá para ter uma única implantação, um monolito modular, com fronteiras tão limpas que substituir o módulo de cotação é um trabalho de duas semanas.
A pesquisa da DORA diz isso sem ambiguidade: a arquitetura, não a escolha de tecnologia, é o que determina o desempenho de entrega, e o padrão vale igual num mainframe e em microsserviços [2]. O que importa é se os times conseguem fazer mudanças grandes sem permissão externa, testar sem ambientes integrados e implantar de forma independente de outros serviços [2].
O que dizem três posições especialistas?
Há um desacordo real aqui, e vale a pena vê-lo antes de escolher.
Posição 1. Componível como direção de mercado (Gartner). A análise da Gartner sustenta que a modularidade componível é um objetivo crescente de arquitetura e investimento, puxado pela demanda por agilidade de negócio, e que a compra empresarial está migrando de suítes monolíticas para componentes intercambiáveis [1]. Sob essa leitura, quem não modularizar fica preso ao ritmo de um fornecedor.
Posição 2. Comece monolito, não fragmente cedo (Martin Fowler). A posição oposta é incômoda e bem documentada. Fowler escreveu que "você não deveria começar um projeto novo com microsserviços, mesmo que tenha certeza de que sua aplicação será grande o bastante para valer a pena", e observou que "quase todas as histórias bem-sucedidas de microsserviços começaram com um monolito que cresceu demais e foi dividido", enquanto "quase todos os casos de sistemas construídos como microsserviços do zero acabaram em problemas sérios" [3]. Sua razão de fundo é que até arquitetos experientes em domínios conhecidos têm enorme dificuldade de acertar as fronteiras no início, e refatorar funcionalidade entre serviços é muito mais difícil do que fazê-lo dentro de um monolito [3].
Posição 3. A costura, não a quantidade (Neo Bernal, cofundador da MasterDragon.AI).
O padrão mais caro que encontro é sempre o mesmo: uma plataforma dividida em mais de dez serviços antes de ter o primeiro cliente. Entregar uma funcionalidade leva dias e exige coordenar várias pessoas. O diagrama é lindo. A operação está travada. Opino sobre isso não porque tenha uma teoria de arquitetura, mas porque o trabalho de desfazer essas separações se parece sempre.
Nesses times a pergunta costuma ser "por que ficamos tão lentos?", e ela só distribui culpa entre quem desenhou o diagrama. A que destrava é outra: "para que separamos cada peça?". Feita serviço por serviço, a maioria não tem resposta.
Com isso à vista, Gartner e Fowler deixam de se contradizer: a Gartner descreve para onde um sistema maduro deve evoluir, e Fowler descreve como chegar lá sem quebrar no caminho. O que resolve a tensão é mudar a unidade de medida, e parar de contar peças para começar a medir custo de mudança. Na prática são três movimentos:
- Comece modular mas implantado junto, com fronteiras internas explícitas e dados com dono claro.
- Defina uma fronteira só onde você já observou o negócio mudando em ritmos diferentes, não onde o diagrama fica mais bonito.
- Extraia uma peça quando tiver o atrito medido, não quando você o intuir.
No entanto, quero ser honesto sobre o limite: isso não diz quantas peças você vai acabar tendo, e às vezes você vai extrair uma costura e descobrir seis meses depois que ela estava no lugar errado. A regra não elimina o erro, apenas o barateia. Uma costura correta se paga sozinha; uma costura prematura se paga duas vezes.
Onde ficam as costuras?
Onde o negócio muda em ritmos diferentes, não onde o organograma tem uma linha.
Esta é a regra prática que usamos: duas capacidades pertencem a peças distintas quando mudam por razões distintas e com frequências distintas. O catálogo muda todo dia, a contabilidade muda com a lei, a identidade quase nunca. Se estão na mesma peça, o ritmo mais lento freia o mais rápido.
Tabela 1. Sinais para colocar ou adiar uma costura.
| Sinal | Colocar costura | Ainda não |
|---|---|---|
| Ritmo de mudança | Muito diferente entre as duas partes | Mudam sempre juntas |
| Times | Times separados com donos claros | Um único time mantém ambas |
| Dados | Cada lado é dono dos seus dados | Compartilham tabelas e transações |
| Fronteiras do domínio | Já provadas por meses de mudanças | Ainda em descoberta |
| Motivo da separação | Atrito observado e medido | O diagrama fica mais bonito |
Repare na última linha. É a que mais custa dinheiro quando é ignorada.
Qual é o pior resultado possível?
O monolito distribuído, e ele é mais comum do que qualquer um dos dois extremos.
Acontece quando você dividiu o sistema em serviços mas manteve o acoplamento: eles compartilham banco de dados, chamam uns aos outros em cadeia para completar uma operação, e precisam ser implantados numa ordem específica. Você paga latência de rede, complexidade de operação, observabilidade distribuída e custo de nuvem, e em troca não ganha a independência que justificava o corte. É o pior dos dois mundos e costuma ser resultado de fragmentar antes de conhecer o domínio, exatamente o risco que Fowler alerta [3].
Como comprovar que uma arquitetura é componível?
Com medidas operacionais, não com o slide de arquitetura.
Um diagrama sempre parece modular. A evidência está em como o time trabalha. A DORA propõe medir exatamente isto: que percentual de mudanças de projeto exige aprovação fora do time, que percentual de implantações precisa ser coordenado com outros serviços, quantas horas por semana vão para coordenação entre times, e quantos repasses existem entre o código pronto e a entrega ao usuário [2].
Se a sua resposta para "este time consegue implantar sua peça hoje sem esperar por ninguém?" for não, você tem acoplamento, não importa quantas caixas o diagrama tenha.
Como aplicamos isso na MasterDragon
Projetamos para o custo da mudança, não para a contagem de serviços.
Nos nossos desenvolvimentos isso vira uma sequência concreta: começamos modular e implantado junto, com fronteiras internas explícitas e dados com dono claro; observamos quais partes mudam em ritmos diferentes durante os primeiros ciclos reais; extraímos uma peça só quando o atrito está medido; e deixamos contratos versionados em cada costura para que a substituição futura não exija negociação. O resultado que buscamos é simples de enunciar e difícil de alcançar: que daqui a três anos você possa trocar qualquer peça sem pedir permissão ao resto do sistema.
Se você está prestes a se comprometer com uma plataforma ou refazer a sua, fale com nossos engenheiros de IA antes de fixar as fronteiras. Comece por como construímos o seu software e veja nosso portfólio de produtos AI-native já lançados. E se a decisão de fundo for construir ou alugar, desenvolvemos isso em software sob medida é ativo, não despesa.
Referências
- Gartner. (2025, fevereiro). Magic Quadrant for Digital Experience Platforms, citado pela MACH Alliance. https://machalliance.org/insights-hub/composable-comes-of-age-in-the-gartner-dxp-magic-quadrant
- DORA. (2025). Loosely coupled teams: capability overview. Google Cloud. https://dora.dev/capabilities/loosely-coupled-teams/
- Fowler, M. (2015, 3 de junho). MonolithFirst. martinfowler.com. https://martinfowler.com/bliki/MonolithFirst.html