Monólito modular vs Microservices: qual arquitetura escolher?

Escolher a arquitetura de uma aplicação é uma das decisões mais importantes no desenvolvimento de software. Essa escolha influencia diretamente a organização do código, a velocidade de desenvolvimento, a facilidade de manutenção, os custos de infraestrutura e a capacidade de evolução do sistema.

Durante muito tempo, aplicações monolíticas foram a abordagem predominante. Com o crescimento das plataformas em nuvem e a popularização de arquiteturas distribuídas, os microservices passaram a ser vistos como uma alternativa para construir sistemas escaláveis e independentes.

Entretanto, existe uma terceira abordagem que merece cada vez mais atenção: o monólito modular.

Essa arquitetura combina a simplicidade operacional de uma aplicação monolítica com uma organização interna baseada em módulos bem definidos. Em muitos cenários, ela permite desenvolver sistemas robustos sem introduzir toda a complexidade de uma arquitetura distribuída.

Mas qual dessas abordagens faz mais sentido para o seu projeto?

Neste artigo, vamos comparar monólito modular e microservices, analisar suas vantagens e desvantagens e mostrar como tomar essa decisão considerando fatores como tamanho da equipe, complexidade do domínio, escalabilidade e custos operacionais. Também veremos como essas arquiteturas podem ser implementadas em projetos com .NET e ASP.NET Core.

O que é um monólito modular?

Um monólito modular é uma aplicação implantada como uma única unidade, mas organizada internamente em módulos independentes, cada um responsável por uma parte específica do negócio.

Em vez de concentrar todas as funcionalidades em uma estrutura desorganizada, a aplicação é dividida em componentes com responsabilidades claras e dependências controladas.

Imagine um sistema de comércio eletrônico desenvolvido em ASP.NET Core. Ele pode conter os seguintes módulos:

• Catálogo de produtos.

• Gestão de clientes.

• Carrinho de compras.

• Processamento de pedidos.

• Pagamentos.

• Controle de estoque.

• Notificações.

Em uma aplicação mal estruturada, esses componentes podem acessar diretamente classes, serviços e tabelas uns dos outros, criando dependências difíceis de controlar.

No monólito modular, cada módulo possui suas próprias regras de negócio, serviços e interfaces de comunicação. O objetivo é impedir que os detalhes internos de um módulo sejam acessados indiscriminadamente por outros componentes.

A aplicação continua sendo executada como uma unidade principal, mas sua estrutura interna favorece o isolamento das responsabilidades.

Como funciona na prática?

Uma organização possível para um projeto ASP.NET Core seria:

Ecommerce/
├── src/
│   ├── Ecommerce.Api/
│   │
│   ├── Modules/
│   │   ├── Catalog/
│   │   │   ├── Domain/
│   │   │   ├── Application/
│   │   │   └── Infrastructure/
│   │   │
│   │   ├── Customers/
│   │   │   ├── Domain/
│   │   │   ├── Application/
│   │   │   └── Infrastructure/
│   │   │
│   │   ├── Orders/
│   │   │   ├── Domain/
│   │   │   ├── Application/
│   │   │   └── Infrastructure/
│   │   │
│   │   └── Payments/
│   │       ├── Domain/
│   │       ├── Application/
│   │       └── Infrastructure/
│   │
│   └── BuildingBlocks/
│
└── tests/
    ├── Catalog.Tests/
    ├── Customers.Tests/
    └── Orders.Tests/

Essa é apenas uma organização ilustrativa. A estrutura exata depende das convenções do projeto e não exige necessariamente a criação de um projeto separado para cada pasta ou camada.

O ponto principal é que cada módulo tenha limites bem definidos.

Por exemplo, o módulo de pedidos pode precisar consultar informações sobre produtos. Isso não significa que ele deva acessar diretamente todas as classes internas do módulo de catálogo.

Em vez disso, os módulos podem se comunicar por meio de interfaces, contratos ou mecanismos explícitos de integração.

Essa separação reduz o acoplamento e torna mais previsível o impacto das alterações.

Quais são as principais vantagens do monólito modular?

A primeira vantagem é a simplicidade operacional.

Como a aplicação é implantada como uma unidade, não é necessário manter uma infraestrutura de comunicação entre dezenas de serviços independentes apenas para executar as funcionalidades do sistema.

A depuração também tende a ser mais simples. O desenvolvedor pode acompanhar boa parte do processamento dentro do mesmo processo, utilizar as ferramentas tradicionais de depuração e executar a aplicação localmente com menos dependências externas.

Outra vantagem é a facilidade para implementar operações que envolvem vários módulos.

Quando os dados estão no mesmo banco de dados relacional e a operação utiliza uma única transação, pode ser mais simples garantir a consistência das alterações do que coordenar transações entre diferentes serviços.

Isso não significa que todas as operações do monólito devam compartilhar uma única transação ou que todos os módulos precisem utilizar o mesmo banco de dados. A arquitetura permite diferentes estratégias, conforme as necessidades do sistema.

O monólito modular também facilita a evolução gradual do projeto. É possível começar com uma estrutura relativamente simples e aprimorar a separação dos módulos à medida que o domínio do negócio se torna mais conhecido.

Essa característica é especialmente útil em projetos novos, nos quais ainda existem incertezas sobre as regras de negócio e os limites naturais entre os componentes.

O que são microservices?

Microservices, ou microsserviços, são uma abordagem arquitetural na qual uma aplicação é dividida em serviços relativamente pequenos, autônomos e organizados em torno de capacidades específicas do negócio.

Diferentemente de um monólito modular tradicional, os microservices possuem limites de execução e implantação independentes.

Cada serviço pode ter seu próprio ciclo de desenvolvimento, processo de implantação, configuração e estratégia de escalabilidade.

Em uma plataforma de comércio eletrônico, por exemplo, poderíamos ter:

Ecommerce Platform
│
├── API Gateway
│
├── Catalog Service
│
├── Customer Service
│
├── Order Service
│
├── Payment Service
│
├── Inventory Service
│
└── Notification Service

Cada serviço é responsável por uma parte do negócio e pode expor funcionalidades por meio de APIs ou mecanismos de mensageria.

O serviço de pedidos, por exemplo, pode registrar uma compra e publicar um evento para que outros componentes iniciem o processamento de pagamento ou atualizem o estoque.

A comunicação entre serviços pode ocorrer de forma síncrona, utilizando HTTP e APIs, ou de forma assíncrona, utilizando filas e sistemas de mensageria.

A escolha depende dos requisitos de latência, disponibilidade, consistência e acoplamento.

O que torna um microservice realmente independente?

Criar vários projetos dentro de uma solução .NET não transforma automaticamente uma aplicação em uma arquitetura de microservices.

Da mesma forma, dividir uma API em vários controllers não significa que o sistema tenha se tornado distribuído.

A independência dos serviços precisa existir em diferentes aspectos.

Primeiro, cada serviço deve ter uma responsabilidade de negócio bem definida.

Segundo, precisa existir uma forma explícita de comunicação com os demais componentes, evitando dependências diretas sobre suas implementações internas.

Terceiro, a arquitetura deve permitir que o serviço seja implantado sem exigir necessariamente a implantação simultânea de todos os outros.

Outro aspecto importante é a propriedade dos dados.

Em uma arquitetura de microservices, cada serviço deve controlar os dados pelos quais é responsável. Isso não significa obrigatoriamente que cada serviço precise de um servidor de banco de dados exclusivo, mas significa que outros serviços não devem depender de acesso direto às suas tabelas internas.

Por exemplo, o serviço de pedidos não deveria alterar diretamente as tabelas internas do serviço de pagamentos. A comunicação deve acontecer por meio de contratos definidos.

Essa separação permite que os serviços evoluam de maneira mais independente, mas exige cuidados adicionais com consistência de dados, comunicação e tratamento de falhas.

Monólito modular vs Microservices: principais diferenças

Embora as duas abordagens possam organizar uma aplicação em módulos de negócio, existem diferenças importantes na forma como esses componentes são executados, implantados e operados.

Critério	Monólito modular	Microservices
Implantação	Aplicação implantada como uma unidade	Serviços implantados independentemente
Execução	Geralmente concentrada em um processo principal	Distribuída entre processos ou unidades de execução
Comunicação interna	Chamadas locais e interfaces entre módulos	APIs, mensageria e outras formas de comunicação distribuída
Complexidade operacional	Geralmente menor	Geralmente maior
Escalabilidade	Normalmente escala a aplicação como um todo	Permite escalar serviços individualmente
Consistência dos dados	Pode utilizar transações locais entre operações relacionadas	Frequentemente exige estratégias de consistência distribuída
Isolamento de falhas	Falhas internas podem afetar o processo da aplicação	Serviços podem isolar algumas falhas, dependendo do desenho
Testes	Pode ser mais simples executar testes de integração localmente	Exige atenção às dependências entre serviços
Equipes	Favorece equipes que trabalham sobre uma aplicação compartilhada	Pode favorecer equipes responsáveis por serviços independentes
Infraestrutura	Pode operar com uma infraestrutura relativamente simples	Pode exigir observabilidade, mensageria e automação mais sofisticadas
Tecnologias	Geralmente utiliza uma stack predominante	Permite stacks diferentes quando existe uma justificativa
Custos	Tende a ter menor custo operacional inicial	Pode ter custos maiores de infraestrutura e operação

É importante destacar que essas diferenças não são absolutas.

Um monólito modular bem projetado pode atender a cargas elevadas e escalar horizontalmente por meio de múltiplas instâncias.

Da mesma forma, uma arquitetura de microservices mal projetada pode apresentar problemas de desempenho, disponibilidade e manutenção, mesmo quando utiliza tecnologias modernas.

A escolha deve considerar os requisitos reais do sistema, e não apenas as características teóricas de cada arquitetura.

Quando escolher um monólito modular?

Para muitos projetos, o monólito modular é um excelente ponto de partida.

Ele oferece uma estrutura capaz de acomodar regras de negócio complexas sem exigir, desde o início, a infraestrutura necessária para administrar uma arquitetura distribuída.

Isso não significa que seja uma solução apenas para aplicações pequenas.

Sistemas empresariais de médio e grande porte também podem se beneficiar dessa abordagem, desde que a organização interna seja consistente e os limites entre os módulos sejam respeitados.

1. Quando o domínio ainda está evoluindo

Em projetos novos, é comum que a equipe ainda não conheça completamente todas as regras de negócio.

Durante o desenvolvimento, processos podem mudar, funcionalidades podem ser incorporadas e responsabilidades inicialmente separadas podem precisar ser reorganizadas.

Em um monólito modular, essas mudanças podem ser mais simples de implementar porque os componentes operam dentro da mesma aplicação.

A equipe pode experimentar diferentes formas de organização sem precisar coordenar alterações simultâneas em vários serviços distribuídos.

Essa flexibilidade é particularmente importante quando os limites entre os domínios ainda não estão suficientemente claros.

2. Quando a equipe é pequena ou média

A arquitetura de software também precisa considerar a capacidade operacional da equipe.

Uma equipe pequena pode não ter disponibilidade para manter pipelines independentes, monitoramento distribuído, infraestrutura de mensageria, políticas de segurança por serviço e processos de implantação para dezenas de componentes.

Nesse cenário, introduzir microservices pode aumentar o trabalho operacional sem gerar benefícios proporcionais.

Um monólito modular permite concentrar os esforços na implementação das funcionalidades e na qualidade do código, mantendo uma estrutura preparada para evoluções futuras.

3. Quando a aplicação exige transações consistentes

Imagine um sistema financeiro que precisa atualizar informações relacionadas a uma operação de negócio.

Se essas alterações estiverem sob a responsabilidade de módulos da mesma aplicação e forem realizadas em uma única transação de banco de dados, será possível utilizar os mecanismos tradicionais de consistência transacional.

Em uma arquitetura distribuída, operações equivalentes podem exigir coordenação entre serviços, compensações ou outros mecanismos para lidar com falhas parciais.

Isso não torna os microservices inadequados para sistemas financeiros. Significa apenas que os requisitos de consistência precisam ser considerados desde o desenho da arquitetura.

4. Quando a infraestrutura precisa permanecer simples

Um monólito modular pode ser executado em uma máquina virtual, em um container ou em uma plataforma de hospedagem gerenciada.

Dependendo dos requisitos, a equipe pode manter uma infraestrutura relativamente enxuta, com menos componentes distribuídos para administrar.

Isso facilita a implantação, a observabilidade e a resolução de problemas, especialmente em equipes que ainda estão amadurecendo seus processos de DevOps.

5. Quando a escalabilidade pode ser resolvida horizontalmente

Nem toda aplicação que recebe mais requisições precisa ser dividida em microservices.

Em muitos casos, é possível executar várias instâncias da mesma aplicação atrás de um balanceador de carga.

Se o sistema for adequadamente projetado para isso, essa estratégia permite distribuir a carga entre diferentes instâncias.

Naturalmente, o banco de dados, o cache, os serviços externos e outros recursos compartilhados também precisam suportar a carga esperada.

Se o problema estiver concentrado em uma funcionalidade específica, entretanto, pode chegar um momento em que escalar a aplicação inteira se torne ineficiente. Esse é um dos cenários em que a extração de um serviço independente pode fazer sentido.

Quando escolher microservices?

Microservices começam a apresentar vantagens mais claras quando os requisitos de autonomia, escalabilidade e organização das equipes justificam os custos de uma arquitetura distribuída.

A decisão não deve ser baseada apenas no tamanho da aplicação ou na quantidade de funcionalidades.

Uma aplicação com muitos módulos pode continuar funcionando muito bem como um monólito modular. Por outro lado, um sistema relativamente menor pode precisar de serviços independentes devido a requisitos específicos de disponibilidade, integração ou isolamento.

1. Quando diferentes partes do sistema precisam escalar de maneira independente

Imagine uma plataforma de comércio eletrônico que possui os seguintes componentes:

• Catálogo de produtos.

• Processamento de pedidos.

• Pagamentos.

• Notificações.

Em determinados períodos, o catálogo pode receber um grande volume de consultas, enquanto o processamento de pedidos apresenta uma carga significativamente menor.

Em um monólito, aumentar a capacidade computacional da aplicação pode beneficiar todas as funcionalidades, mesmo que apenas uma delas precise de mais recursos.

Com microservices, é possível dimensionar os serviços de forma independente.

O serviço de catálogo pode receber mais instâncias, enquanto o processamento de pedidos mantém sua capacidade atual.

Essa estratégia pode melhorar a utilização dos recursos, desde que os custos adicionais de infraestrutura e comunicação não anulem os benefícios.

2. Quando existem equipes responsáveis por domínios independentes

Em organizações maiores, diferentes equipes podem ser responsáveis por capacidades distintas do negócio.

Uma equipe pode cuidar dos pagamentos, enquanto outra trabalha no catálogo e uma terceira mantém os serviços de logística.

Quando os limites dos domínios estão bem definidos, os microservices podem permitir que essas equipes desenvolvam, testem e implantem suas funcionalidades com maior autonomia.

Entretanto, essa independência não acontece automaticamente.

Se dois serviços dependem de alterações simultâneas em seus contratos ou se várias equipes precisam modificar continuamente o mesmo conjunto de dados, a arquitetura continuará apresentando acoplamento, mesmo com os componentes separados.

3. Quando os ciclos de implantação precisam ser independentes

Considere um sistema em que o módulo de notificações recebe melhorias frequentes, mas o processamento financeiro precisa seguir um processo de validação mais rigoroso.

Se ambos estiverem em um monólito, a implantação normalmente envolverá a aplicação inteira, mesmo quando a alteração estiver limitada às notificações.

Com microservices, o serviço de notificações pode ser implantado de forma independente, desde que seus contratos permaneçam compatíveis com os demais componentes.

Isso pode reduzir o impacto das alterações e permitir ciclos de entrega diferentes para cada domínio.

Ainda assim, a implantação independente exige testes automatizados, versionamento de contratos e estratégias adequadas para lidar com incompatibilidades.

4. Quando existem requisitos específicos de isolamento

Alguns componentes podem exigir políticas próprias de segurança, disponibilidade ou escalabilidade.

Por exemplo, um serviço responsável por processar documentos pode precisar de recursos computacionais diferentes dos utilizados pela API principal.

Outro serviço pode precisar de uma política específica de acesso à rede ou de um ambiente de execução isolado.

A arquitetura de microservices pode facilitar esse tipo de separação, embora o nível de isolamento efetivo dependa da infraestrutura e da configuração adotadas.

5. Quando a organização possui maturidade operacional

Uma arquitetura distribuída exige mais do que desenvolver APIs independentes.

A equipe precisa conseguir implantar os serviços com segurança, identificar falhas, acompanhar métricas e rastrear requisições que atravessam diferentes componentes.

Também é necessário planejar aspectos como:

• Logs centralizados.

• Métricas e alertas.

• Rastreamento distribuído.

• Gestão de segredos e configurações.

• Automação de builds e implantações.

• Políticas de autenticação e autorização.

• Tratamento de indisponibilidade de serviços.

• Estratégias para consistência dos dados.

• Testes de integração entre componentes.

Sem essas capacidades, o aumento do número de serviços pode tornar a operação mais difícil do que a manutenção de uma aplicação monolítica.

Os principais desafios dos microservices

Os microservices oferecem vantagens importantes, mas também introduzem problemas que precisam ser considerados durante o planejamento.

Comunicação entre serviços

Em um monólito modular, uma chamada entre módulos normalmente acontece dentro do mesmo processo.

Em uma arquitetura distribuída, uma chamada HTTP depende de uma rede, de um serviço remoto e de vários componentes de infraestrutura.

Essa comunicação pode apresentar latência, falhas temporárias, timeouts e indisponibilidade.

Por isso, chamadas remotas precisam ser projetadas com limites de tempo, políticas de repetição adequadas e tratamento de erros.

É importante evitar novas tentativas indiscriminadas, pois elas podem aumentar a carga justamente quando um serviço já está sobrecarregado.

Consistência dos dados

Quando uma operação envolve vários microservices, não é possível presumir que uma única transação local de banco de dados garanta a consistência de toda a operação.

Imagine um pedido que precisa ser registrado, pago e associado a uma atualização de estoque.

Se o pagamento for aprovado, mas a atualização do estoque falhar, o sistema precisará definir como tratar essa situação.

Uma possibilidade é utilizar uma saga, na qual uma operação de negócio é dividida em etapas coordenadas, com ações compensatórias para determinados cenários de falha.

Também podem ser utilizados eventos e mecanismos de processamento assíncrono.

Essas soluções exigem atenção a duplicidade de mensagens, idempotência, reprocessamento e monitoramento.

Observabilidade

Quando uma requisição atravessa vários serviços, identificar a origem de um problema pode ser mais difícil.

Um erro aparentemente ocorrido no serviço de pedidos pode ter sido provocado por uma falha no serviço de pagamentos ou por um timeout em uma dependência externa.

Por isso, logs estruturados, métricas e rastreamento distribuído são fundamentais para acompanhar o comportamento da aplicação.

Identificadores de correlação também ajudam a relacionar os eventos gerados por diferentes componentes durante o processamento de uma mesma operação.

Custos de infraestrutura e operação

Cada serviço pode exigir recursos de execução, configurações, pipelines, monitoramento e mecanismos de segurança.

Mesmo quando os serviços compartilham uma infraestrutura de hospedagem, o aumento da quantidade de componentes pode elevar o custo de operação e a complexidade da manutenção.

O impacto financeiro depende da arquitetura, do volume de tráfego, da plataforma utilizada e do nível de disponibilidade exigido.

Portanto, não é correto afirmar que microservices são sempre mais caros ou sempre mais baratos. A avaliação deve considerar o custo total da solução, incluindo infraestrutura, engenharia e operação.

Como implementar um monólito modular em .NET?

O ecossistema .NET oferece recursos que facilitam a construção de aplicações organizadas em módulos.

Com ASP.NET Core, é possível estruturar a aplicação em projetos ou componentes internos, registrar serviços de maneira organizada e definir contratos para a comunicação entre módulos.

Uma abordagem prática é começar pela separação das responsabilidades do negócio.

1. Organize o código por domínio

Em vez de organizar toda a aplicação exclusivamente por camadas técnicas, considere agrupar os componentes relacionados a cada capacidade do negócio.

Por exemplo:

src/
├── MyApp.Api/
├── MyApp.Catalog/
├── MyApp.Orders/
├── MyApp.Customers/
└── MyApp.Payments/

Cada projeto pode conter suas próprias camadas internas, conforme a complexidade do domínio.

O projeto de pedidos, por exemplo, pode manter suas entidades, regras de negócio e serviços de aplicação sem expor toda a implementação para os demais módulos.

A separação em projetos facilita a aplicação de regras de dependência durante a compilação, mas não substitui a necessidade de definir limites arquiteturais claros.

2. Controle as dependências entre módulos

Um dos principais riscos de um monólito modular é permitir que a aplicação volte gradualmente a se comportar como um monólito desorganizado.

Isso acontece quando módulos passam a acessar diretamente as implementações internas uns dos outros.

Para evitar esse problema, defina contratos explícitos para as operações que precisam ser compartilhadas.

Por exemplo, o módulo de pedidos pode depender de uma abstração que permite consultar informações de um produto, sem conhecer os detalhes internos do módulo de catálogo.

Também é possível utilizar eventos internos para comunicar fatos relevantes do domínio, desde que exista uma definição clara sobre o comportamento esperado e o tratamento de falhas.

O objetivo é preservar o isolamento lógico dos módulos, mesmo que eles sejam executados no mesmo processo.

3. Defina a propriedade dos dados

Mesmo em um monólito modular, vale a pena estabelecer qual módulo é responsável por cada conjunto de dados.

O módulo de clientes deve controlar as regras de negócio relacionadas aos clientes. O módulo de pedidos deve controlar as regras associadas aos pedidos.

Essa organização ajuda a impedir que diferentes partes da aplicação alterem os mesmos dados sem respeitar as regras do domínio responsável.

É possível utilizar um único banco de dados físico, desde que o acesso aos dados seja organizado e as dependências sejam controladas.

Quando necessário, também é possível utilizar schemas diferentes ou outras formas de separação lógica.

O importante é não confundir a existência de um banco compartilhado com a ausência obrigatória de modularidade.

4. Crie testes para proteger os limites arquiteturais

Os testes automatizados devem verificar não apenas as regras de negócio, mas também as dependências que podem comprometer a modularidade.

Por exemplo, é possível estabelecer que o módulo de catálogo não pode depender diretamente da infraestrutura do módulo de pagamentos.

Também é importante testar os contratos utilizados para a comunicação entre os módulos e garantir que alterações internas não provoquem regressões em outras áreas do sistema.

Essas verificações ajudam a manter a arquitetura consistente ao longo do tempo.

5. Prepare a aplicação para implantação e escala

Um monólito modular não precisa ser uma aplicação executada em uma única máquina.

Ele pode ser empacotado em um container e executado em várias instâncias, desde que tenha sido projetado para isso.

Para permitir a execução de múltiplas instâncias, considere aspectos como armazenamento de sessões, processamento de tarefas em segundo plano, cache distribuído e coordenação de tarefas que não devem ser executadas simultaneamente por todas as instâncias.

Essas preocupações não são exclusivas de microservices.

Uma aplicação monolítica bem estruturada pode atender a requisitos relevantes de disponibilidade e escalabilidade sem precisar distribuir todos os seus módulos em serviços independentes.

Como evoluir de um monólito modular para microservices?

Uma das vantagens de começar com um monólito modular é a possibilidade de evoluir a arquitetura conforme as necessidades reais do sistema.

Entretanto, essa evolução exige planejamento.

O objetivo não deve ser transformar cada módulo em um microservice, mas identificar quais componentes realmente se beneficiariam de uma implantação e operação independentes.

Imagine que uma plataforma de comércio eletrônico tenha começado como um monólito modular.

Com o crescimento do negócio, o módulo de notificações passa a apresentar requisitos diferentes dos demais componentes. Ele precisa processar grandes volumes de mensagens e utilizar uma infraestrutura própria para lidar com tarefas assíncronas.

Nesse cenário, a equipe pode avaliar a extração do módulo de notificações para um serviço independente.

Uma estratégia possível envolve as seguintes etapas.

Etapa 1: identifique o módulo que apresenta uma necessidade concreta

Comece por uma funcionalidade cujo isolamento ofereça um benefício claro.

Pode ser um componente que precisa escalar de forma independente, possui um ciclo de implantação muito diferente ou apresenta requisitos específicos de disponibilidade.

Evite escolher um módulo apenas porque ele parece pequeno ou porque a arquitetura atual está na moda.

Etapa 2: estabeleça um contrato de comunicação

Antes de separar o componente, defina como o restante da aplicação irá interagir com ele.

Dependendo do cenário, a comunicação pode utilizar uma API HTTP, eventos ou mensageria.

O contrato precisa deixar claro quais operações são disponibilizadas, quais dados são necessários e como os erros serão tratados.

Etapa 3: separe a propriedade dos dados

Identifique quais dados pertencem ao módulo e quais componentes ainda dependem diretamente deles.

A extração pode exigir a criação de uma estrutura própria de armazenamento e a migração gradual dos acessos.

É importante evitar que o novo serviço continue dependendo de acesso direto às tabelas internas do monólito, pois isso mantém um acoplamento que dificulta a evolução independente.

Etapa 4: prepare a operação do novo serviço

Configure a implantação, o monitoramento, a gestão de segredos e os mecanismos de comunicação necessários.

Também é preciso definir como o sistema se comportará quando o serviço estiver indisponível.

Por exemplo, uma falha temporária no serviço de notificações não deveria necessariamente impedir a conclusão de um pedido já registrado.

Uma fila de mensagens pode ajudar a desacoplar o processamento, desde que sejam definidos mecanismos adequados para reprocessamento e tratamento de falhas.

Etapa 5: migre a responsabilidade gradualmente

A extração pode ocorrer em etapas, mantendo a aplicação funcional durante a transição.

O padrão Strangler Fig é uma das estratégias utilizadas para modernizar sistemas gradualmente, direcionando determinadas funcionalidades para novas implementações enquanto o sistema anterior continua operando.

Durante a migração, é necessário evitar que o mesmo processamento seja executado simultaneamente nos dois componentes ou que os dados fiquem inconsistentes.

Por isso, a transição precisa incluir testes, monitoramento e um plano de reversão apropriado.

Etapa 6: avalie os resultados

Depois da extração, compare os resultados com os objetivos definidos no início.

O serviço passou a escalar de maneira mais eficiente? A equipe ganhou autonomia? O ciclo de implantação ficou mais rápido? A complexidade operacional aumentou além do esperado?

Essas respostas ajudam a decidir se vale a pena continuar a decomposição ou se a arquitetura atual já atende às necessidades do negócio.

Monólito modular e microservices podem coexistir?

Sim. Na prática, muitas arquiteturas podem combinar as duas abordagens.

Uma aplicação pode manter grande parte das funcionalidades em um monólito modular e utilizar serviços independentes para capacidades que realmente exigem autonomia.

Por exemplo, um sistema empresarial pode manter módulos de clientes, pedidos e faturamento na aplicação principal, enquanto utiliza um serviço separado para processamento de documentos ou envio de notificações.

Essa abordagem evita a necessidade de distribuir todos os componentes da aplicação e permite concentrar a complexidade operacional onde ela oferece benefícios concretos.

Entretanto, a coexistência também exige disciplina.

Os limites entre os módulos internos e os serviços externos precisam estar claros. Caso contrário, a solução pode acumular os problemas de um monólito excessivamente acoplado e as dificuldades de uma arquitetura distribuída.

O objetivo deve ser encontrar o equilíbrio entre simplicidade e autonomia.

Monólito modular vs Microservices: qual arquitetura escolher em 2026?

Não existe uma resposta universal, mas é possível estabelecer critérios para orientar a decisão.

Para um projeto novo, com domínio ainda em evolução, equipe reduzida e requisitos de escala conhecidos, um monólito modular costuma ser uma escolha inicial bastante razoável.

Ele permite desenvolver funcionalidades, validar hipóteses e organizar o código sem assumir antecipadamente todos os custos de uma arquitetura distribuída.

Por outro lado, quando o sistema possui domínios bem delimitados, equipes que precisam trabalhar de maneira independente e requisitos concretos de implantação ou escalabilidade por componente, microservices podem oferecer vantagens importantes.

A decisão também precisa considerar a maturidade da organização. Uma equipe que ainda não possui processos sólidos de automação, monitoramento e gestão de falhas pode encontrar dificuldades significativas ao operar muitos serviços independentes.

Para facilitar a análise, utilize as seguintes perguntas:

Pergunta	Se a resposta for sim
O domínio do negócio ainda está mudando frequentemente?	Considere começar com um monólito modular.
A equipe precisa manter uma infraestrutura simples?	Um monólito modular pode ser mais adequado.
O sistema precisa escalar de forma diferente em áreas específicas?	Avalie microservices para os componentes que justificam essa necessidade.
Existem equipes independentes responsáveis por domínios bem definidos?	Microservices podem favorecer a autonomia entre equipes.
As implantações precisam ocorrer de forma independente?	Avalie a separação dos componentes envolvidos.
A organização já possui observabilidade e automação maduras?	A operação de microservices tende a ser mais viável.
Ainda não existe uma justificativa concreta para distribuir a aplicação?	Evite introduzir essa complexidade prematuramente.

Essas perguntas não substituem uma análise arquitetural completa, mas ajudam a identificar quais fatores devem ter maior peso na decisão.

Conclusão

A discussão entre monólito modular e microservices não deve ser tratada como uma escolha entre uma arquitetura ultrapassada e outra moderna.

As duas abordagens resolvem problemas diferentes e apresentam vantagens e limitações que precisam ser avaliadas de acordo com o contexto.

O monólito modular oferece uma combinação interessante de organização interna, facilidade de desenvolvimento e simplicidade operacional. Ele permite construir aplicações robustas, manter responsabilidades bem definidas e preparar o sistema para evoluções futuras.

Os microservices, por sua vez, oferecem autonomia de implantação, escalabilidade independente e maior flexibilidade para organizações que precisam distribuir o desenvolvimento e a operação entre diferentes equipes.

Entretanto, essas vantagens vêm acompanhadas de desafios relacionados à comunicação, consistência dos dados, observabilidade, segurança e custos operacionais.

Para desenvolvedores .NET, uma estratégia prática é começar com módulos bem definidos, estabelecer contratos claros entre as partes do sistema e utilizar testes automatizados para proteger os limites arquiteturais.

Quando surgirem necessidades concretas de autonomia, determinados módulos poderão ser extraídos para serviços independentes.

A melhor arquitetura não é necessariamente a que utiliza mais tecnologias ou possui mais componentes. É aquela que resolve os problemas atuais do negócio, permite evoluir com segurança e mantém a complexidade sob controle.

E, no seu próximo projeto, a pergunta mais importante talvez não seja se você deve utilizar microservices, mas se existe um problema real que justifique adotá-los.