Entenda o significado de Modular Monolith Architecture e aprenda a aplicá-la para garantir um desenvolvimento ágil com estabilidade e escalabilidade. 

A arquitetura de software é um dos pilares fundamentais para o sucesso de qualquer projeto de desenvolvimento. E entre as diversas abordagens disponíveis, a Modular Monolith Architecture — que pode ser compreendida como Arquitetura Monolito Modular, em tradução livre — tem ganhado destaque por combinar a simplicidade de um monolito com a modularidade de microsserviços.  

A seguir, entenda o que é essa arquitetura de software, seus benefícios e como colocá-la em prática utilizando .NET Core 9 com C#. 

Boa leitura! 

Navegue pelo índice

    O que é Modular Monolith Architecture? 

    A Modular Monolith Architecture é uma abordagem de design de software que organiza o código em módulos independentes, mas que ainda residem em uma base e são implantados como uma unidade. Cada módulo é responsável por uma funcionalidade específica do sistema, como gerenciamento de usuários, processamento de pedidos ou relatórios. 

    Essa arquitetura promove a separação de preocupações, facilitando manutenção, testes e evolução do sistema. A Modular Monolith Architecture incentiva a criação de módulos bem definidos com dependências mínimas entre si, ao contrário de um monolito tradicional, em que o código é frequentemente entrelaçado. 

    E para deixar a compreensão ainda mais fácil, entenda a seguir alguns conceitos fundamentais desse método de desenvolvimento: 

    • Monolito modular: um sistema único, mas que é dividido em módulos internos que encapsulam funcionalidades específicas, como o módulo de usuários. 
    • Baixo acoplamento: os módulos são projetados para depender o mínimo possível uns dos outros, facilitando a manutenção e a evolução do sistema. 
    • Alta coesão: cada módulo é responsável por uma área de negócio ou funcionalidade, seguindo o princípio da responsabilidade única. 
    • Comunicação interna: a interação entre os módulos ocorre por meio de interfaces bem definidas, chamadas de métodos ou eventos internos. 

    Leia mais: 

    Comparação com outras arquiteturas 

    Ao comparar com o monolito tradicional, a vantagem da Modular Monolith Architecture é a simplicidade de desenvolvimento, deploy único e facilidade de debug. Já a principal desvantagem é seu acoplamento alto, dificuldade de escalar partes específicas do sistema e manutenção complexa à medida que cresce. 

    Em relação a microservices, a Modular Monolith Architecture tem escalabilidade independente, flexibilidade tecnológica e facilidade de manutenção em sistemas grandes e complexos. Porém, há uma maior latência na comunicação entre serviços e desafios na consistência de dados. 

    Por fim, a modular monolith combina a simplicidade do monolito com a organização dos microservices, facilitando a evolução para essa última no futuro, caso seja necessário. No entanto, requer disciplina no design para evitar acoplamento excessivo entre módulos. 

    Modular Monolith Architecture vs Microservices 

    Uma das grandes dúvidas para devs em geral que desejam utilizar essa arquitetura está relacionada aos microsserviços. Por isso, vamos aprofundar ainda mais este tópico. Enquanto os microservices dividem a aplicação em serviços independentes que podem ser implantados e escalados separadamente, como dito anteriormente, a Modular Monolith Architecture mantém a aplicação como uma unidade que possui uma estrutura interna modular. 

    A principal diferença entre ambas as arquiteturas está na complexidade operacional. Os microsserviços exigem infraestrutura para gerenciar comunicação entre serviços, balanceamento de carga, monitoramento etc. Já a Modular Monolith Architecture simplifica essa operação, pois todos os módulos são executados ao mesmo tempo. 

    Quando adotar essa abordagem 

    A Modular Monolith Architecture é ideal em cenários como projetos em crescimento, quando você precisa de uma arquitetura organizada, mas ainda não justifica a complexidade dos microservices. 

    Outro fator para considerar usar esse modelo de desenvolvimento está relacionado a equipes pequenas ou com recursos limitados. Isso porque a Modular Monolith Architecture facilita o processo de criação e o deploy sem demandar uma infraestrutura complexa. 

    Por fim, vale aplicar essa arquitetura quando se trata de sistemas com domínios bem definidos. Nesse caso, a medida pode ser adotada quando o problema pode ser dividido em áreas de responsabilidade distintas. 

    Quando a arquitetura pode não ser a melhor escolha 

    Apesar de suas vantagens, a Modular Monolith Architecture não é adequada para todos os cenários. Aqui estão algumas situações em que outras abordagens podem ser mais indicadas: 

    • Sistemas altamente distribuídos: se o sistema precisa ser implantado em diferentes regiões geográficas ou em ambientes com requisitos de escalabilidade extrema, os microservices podem ser mais adequados. 
    • Equipes grandes e distribuídas: em organizações com muitas equipes trabalhando de forma independente, a complexidade de coordenar o desenvolvimento em um único monolito pode ser maior. 
    • Tecnologias heterogêneas: caso diferentes partes do sistema precisarem ser desenvolvidas com tecnologias ou linguagens completamente diferentes, os microservices oferecem mais flexibilidade. 
    • Projetos pequenos ou de curta duração: para sistemas simples ou de vida útil limitada, a complexidade adicional de modularizar o monolito pode não justificar o esforço. 

    Quais são os benefícios da Modular Monolith Architecture? 

    Ao todo, são cinco as vantagens em adotar esse modelo de arquitetura de software em seus projetos: 

    1. Simplicidade operacional: como a aplicação é implantada como uma unidade, não há necessidade de gerenciar múltiplos serviços ou infraestrutura complexa. 
    1. Facilidade de desenvolvimento: desenvolvedores podem trabalhar em módulos específicos sem se preocupar com o impacto em outras partes do sistema. 
    1. Manutenção simplificada: a separação em módulos facilita a identificação e correção de bugs, além de permitir atualizações pontuais. 
    1. Escalabilidade: embora a aplicação seja um monolito, módulos críticos podem ser otimizados ou escalados separadamente, se necessário. 
    1. Transição para microsserviços: se no futuro a aplicação precisar evoluir para microsserviços, a modularidade já existente facilita essa transição. 

    A Modular Monolith Architecture é uma abordagem que oferece o melhor dos dois mundos: a simplicidade e a facilidade de deploy de um monolito tradicional, combinadas com a organização e a escalabilidade de uma arquitetura modular. Essa junção a torna uma escolha ideal para projetos que precisam crescer de forma sustentável, sem a complexidade operacional dos microservices. 

    Quer aprender na prática? Confira o passo a passo de um projeto em Modular Monolith Architecture 

    Agora que você já conhece os conceitos e benefícios, vamos colocar a mão na massa! Quer aprender a criar um projeto básico em .NET Core 9 com C# utilizando Modular Monolith Architecture? É só conferir as seguintes camadas: 

    1. Domain: contém as entidades e regras de negócio. 
    1. Application: implementa a lógica de aplicação e orquestração. 
    1. Infrastructure: responsável pela persistência de dados e integrações externas. 
    1. Presentation: camada de interface com o usuário (API ou UI). 

    Passo a passo: criando o projeto 

    Primeiro, é preciso criar uma solução .NET Core

    dotnet new sln -n ModularMonolith 

    Em seguida, desenvolva os projetos para cada camada, desta forma: 

    dotnet new classlib -n Domain 

    dotnet new classlib -n Application 

    dotnet new classlib -n Infrastructure 

    dotnet new webapi -n Presentation 

    É aí que é possível adicionar os projetos à solução, deste modo: 

    dotnet sln add Domain 

    dotnet sln add Application 

    dotnet sln add Infrastructure 

    dotnet sln add Presentation 

    Por fim, configure as dependências entre os projetos. Mas, atenção, é preciso considerar que: 

    • Application depende de Domain. 
    • Infrastructure depende de Domain e Application. 
    • Presentation depende de Application e Infrastructure. 

    Ponto entendido? Então, basta usar os comandos abaixo para adicionar as referências

    dotnet add Application reference Domain 

    dotnet add Infrastructure reference Domain Application 

    dotnet add Presentation reference Application Infrastructure 

    Codificação básica de todas as camadas 

    Inicialmente, em Domain, crie uma entidade simples, como Product, no projeto Domain: 

    namespace Domain.Entities 

    { 

    public class Product 

    { 

    public int Id { get; set; } 

    public string Name { get; set; } 

    public decimal Price { get; set; } 

    } 

    } 

    Depois, em Application, elabore um serviço para gerenciar produtos no projeto nele: 

    using Domain.Entities; 

    namespace Application.Services 

    { 

    public interface IProductService 

    { 

    Product GetProductById(int id); 

    } 

    public class ProductService : IProductService 

    { 

    public Product GetProductById(int id) 

    { 

    // Simulação de busca no banco de dados 

    return new Product { Id = id, Name = “Sample Product”, Price = 99.99m }; 

    } 

    } 

    } 

    Já em Infrastructure, configure o acesso a dados no projeto. Aqui, usaremos um repositório simples: 

    using Domain.Entities; 

    using Application.Services; 

    namespace Infrastructure.Repositories 

    { 

    public class ProductRepository : IProductService 

    { 

    public Product GetProductById(int id) 

    { 

    // Simulação de acesso ao banco de dados 

    return new Product { Id = id, Name = “Sample Product”, Price = 99.99m }; 

    } 

    } 

    } 

    E, para concluir, em Presentation, crie um controlador para expor uma API: 

    using Microsoft.AspNetCore.Mvc; 

    using Application.Services; 

    namespace Presentation.Controllers 

    { 

    [ApiController] 

    [Route(“api/[controller]”)] 

    public class ProductsController : ControllerBase 

    { 

    private readonly IProductService _productService; 

    public ProductsController(IProductService productService) 

    { 

    _productService = productService; 

    } 

    [HttpGet(“{id}”)] 

    public IActionResult GetProduct(int id) 

    { 

    var product = _productService.GetProductById(id); 

    return Ok(product); 

    } 

    } 

    } 

    A configuração final fica por conta do arquivo Program.cs do projeto Presentation, no qual os serviços serão registrados como segue: 

    using Application.Services; 

    using Infrastructure.Repositories; 

    var builder = WebApplication.CreateBuilder(args); 

    // Registrar serviços 

    builder.Services.AddScoped<IProductService, ProductRepository>(); 

    var app = builder.Build(); 

    app.MapControllers(); 

    app.Run(); 

    De modo geral, você viu que a Modular Monolith Architecture é uma excelente escolha para projetos que precisam de uma estrutura organizada e escalável, sem a complexidade operacional dos microsserviços. Com o exemplo prático em .NET Core 9 com C#, você pode começar a aplicar essa arquitetura em seus projetos e aproveitar seus benefícios. 

    Experimente expandir o exemplo, adicionando mais módulos e funcionalidades, e veja como essa abordagem pode simplificar o desenvolvimento e a manutenção do seu software

    E para fazer com que seus projetos de desenvolvimento performem de forma eficiente, nada melhor do que contar com um servidor VPS. Com ele, você garante, além de performance, estabilidade.  

    A Locaweb oferece o serviço de VPS, com máquinas robustas para aplicações de alta demanda, disponibilidade com infraestrutura no Brasil e suporte em português 24/7. Tudo isso com a grande vantagem da cobrança em Real. Saiba mais no site! 

    O autor

    Rodrigo Cardoso (Pokemaobr)

    Conhecido como Poke, é Streamer (Live "Coder") na Twitch, Web Developer e apresentador do talk show "The Velopers". Com bacharelado em Matemática e MBA em SOA, Poke atua como desenvolvedor e organizador de eventos de TI. É evangelista PHPSP e criador do PokePHP, focando em disseminar conteúdos técnicos e humor para a comunidade de desenvolvedores. Nas horas vagas, ele adora se conectar com a comunidade e compartilhar seu conhecimento de maneira divertida e informativa.

    Veja outros conteúdos desse autor