Arquitetura Monolítica

Monolito é quando todo o sistema vive em uma única aplicação: interface, regras de negócio e acesso a dados ficam no mesmo código, rodando como uma peça só. É a forma mais comum de começar um projeto.

Como é por dentro

+----------------------------+
|         Monolito           |
|  +----------------------+  |
|  |   Interface (UI)     |  |
|  +----------------------+  |
|  |   Regras de negócio  |  |
|  +----------------------+  |
|  |   Acesso a dados     |  |
|  +----------------------+  |
+----------------------------+
            |
        Banco de dados

Tudo é compilado e implantado junto. Uma mudança em qualquer parte exige publicar o sistema inteiro de novo.

Vantagens

• Simples de começar: um repositório, um deploy.
• Fácil de depurar: tudo roda no mesmo processo.
• Chamadas internas são rápidas, sem rede no meio.
• Menos infraestrutura para manter.

Desvantagens

• Cresce e fica difícil de entender.
• Um erro pode derrubar o sistema todo.
• Escalar significa duplicar a aplicação inteira, mesmo que só uma parte precise.
• Times grandes pisam no pé uns dos outros no mesmo código.

Quando usar

Monolito é ótimo para:

• Projetos novos e MVPs, quando você ainda valida a ideia.
• Times pequenos.
• Domínios simples ou pouco definidos.

A regra prática: comece monolito. Só quebre em serviços menores quando a dor de manter um bloco único ficar maior que a dor de gerenciar várias partes. Muitos sistemas vivem bem como monolitos por anos.

Monolito bem organizado

Monolito não precisa ser bagunçado. Separe o código em módulos com fronteiras claras:

/pedidos
/clientes
/pagamentos

Isso facilita extrair um módulo para um serviço próprio no futuro, se necessário. Organização interna vale mais que a escolha entre monolito e microserviços.