Um processo pode ter fronteiras fortes
No curso, Catalogo cuida da descrição das aulas; Matriculas controla quem tem acesso; Progresso registra o avanço. Um monólito modular mantém esses módulos no mesmo deploy, mas restringe chamadas e propriedade dos dados por contratos explícitos.
Abrir diagrama em tamanho original
Compartilhar um banco físico pode ser uma decisão pragmática. O risco aparece quando qualquer módulo lê e altera tabelas internas de outro: a mudança atravessa limites invisíveis. Comece com regras de importação, APIs internas e propriedade clara. Separar schemas pode ajudar, mas não substitui esses contratos.
Uma transação local costuma ser simples e consistente. Se uma operação cruza módulos, decida quem é dono da regra e da transação antes de extrair serviço. Limites bem formados preservam essa possibilidade sem exigir que ela aconteça agora.
Vídeo previsto para 03/11/2026.
Recupere: o que torna um monólito modular diferente de um projeto com pastas chamadas catalogo, matricula e progresso?
Pratique com /aprender
/aprender Considere um backend único com Catálogo, Matrículas e Progresso. Peça que eu atribua a cada módulo a propriedade de tabelas e contratos. Introduza uma consulta direta que cruza os módulos e me pergunte que acoplamento ela cria.