Dicução sobre abordagem entre microserviços vs monólito modular.
A discução sobre a abordagem de uma ou outra arquitetura nnormalmente se da apenas em comparar a topologia de deployment como se podesemos definir a qualidade do software por essas metricas, o que de fato e um erro. Um dos eixos que quero mostrar aqui e um forma diferente de pensar.
Modularidade e limites (boundaries): controlar acoplamento e separar responsabilidades.
Operação e evolução: Entregas, Observabilidade e mudanças no sistema ao longo do tempo.
Com algumas respontar podemos ja ter uma ideia de onde ir e não seguir um padrao como uma religião e sim como uma estrategia para otimizações e trade-offs sob restrições tecnicas e organizacionais.
Vamos as Definições
Microserviços (MS)
Um sistema distribuído composto por múltiplos serviços deployáveis de forma independente, com fronteiras explícitas (APIs/contratos), e tipicamente com autonomia de dados (ou, no mínimo, autonomia de mudança). O “valor” prometido não é modularidade; é independência operacional e organizacional.
Corolário: microserviços não “criam” boundaries; eles forçam boundaries. Se o domínio não suporta boas fronteiras, você só distribui o caos.
Monólito modular (MM)
Um único artefato deployável (ou poucos artefatos) com módulos fortemente encapsulados e dependências controladas (ports/adapters, camadas, módulos, packages, etc.). O ganho central é alto throughput de mudança com baixo overhead operacional, mantendo disciplina de design.
Corolário: um monólito não é “big ball of mud” por definição. O oposto de microserviços não é “bagunça”; é modularidade dentro do mesmo deployment.