Aplicações monolíticas representam a arquitetura tradicional de desenvolvimento de software, caracterizada por serem implementadas como uma única unidade de deployment onde todos os componentes estão integrados em um processo unificado.
Existe uma percepção equivocada de que sistemas monolíticos são:
- Tecnologia ultrapassada da década anterior
- Arquiteturas que não escalam adequadamente
- Impeditivos para o crescimento do negócio
- Inerentemente acoplados
Grande parte desses argumentos são falsos e baseados em preconceitos arquiteturais.
Sistemas monolíticos são recomendados em cenários específicos:
- Projetos novos onde o modelo de negócio não está claramente definido
- Situações de instabilidade no core do negócio
- Necessidade de evitar complexidade no processo de deployment
- Ambientes que requerem simplicidade operacional
- Alto acoplamento: Todos os componentes compartilham o mesmo processo
- Modular: Organização em módulos com responsabilidades específicas
- Modular com bancos segregados: Separação de dados por contexto
Sistemas que mantêm características monolíticas mas com componentes fisicamente separados.
Sistemas onde a arquitetura interna não é visível ou acessível externamente.
Em sistemas mal estruturados, uma entidade User pode acumular responsabilidades excessivas:
- Dados pessoais, endereços, cartões de crédito
- Tickets de suporte, histórico de compras
- Carrinho abandonado, devoluções, financiamento
- Indicações, reclamações, email marketing
- Campanhas, favoritos, lista de casamento
- Histórico de login, preferências de email
- Avaliações de produtos, dados de CRM
- Propostas, lances em leilões, cartão de pontos
- Ausência de contextos bem definidos
- Entidades com relacionamentos excessivos
- Falta de separação de responsabilidades
- Alto risco de efeitos colaterais indesejados
- Módulos organizados em Bounded Contexts
- Comunicação através de contratos e facades
- Entidades específicas por contexto com atributos necessários
- Equipes especializadas por módulo
- Alta coesão: componentes que mudam juntos permanecem juntos
A aplicação de Domain-Driven Design permite definir contextos específicos:
- Catálogo: User como consumidor de produtos
- Carrinho: User como comprador ativo
- Checkout: User como finalizador de pedidos
- Pagamentos: Cliente como pagador
- Suporte: Cliente como solicitante de ajuda
- Marketing: Lead como prospect
- Programa de pontos: Beneficiário como acumulador
- Lista de casamento: Convidado como participante
Cada contexto se torna um módulo independente com responsabilidades bem definidas.
Esta abordagem mantém as características modulares mas implementa bases de dados separadas por contexto, proporcionando maior independência de dados entre módulos.
- Deployment único: Simplicidade no processo de entrega
- Operação unificada: Menor complexidade operacional
- Observabilidade simplificada: Monitoramento centralizado
- Comunicação interna: Sistemas integrados sem overhead de rede
- Governança reduzida: Tecnologia e linguagem unificadas