Skip to content

Monólito Modular: Equilíbrio entre Coesão e Isolamento

Em sistemas de saúde complexos, a escolha da arquitetura macro é um dos pilares mais críticos. O Monólito Modular foi adotado como a estrutura base do projeto por oferecer o melhor equilíbrio entre produtividade, segurança de tipos (Type Safety) e preparação para o futuro.

O Desafio da Saúde Digital

Diferente de sistemas de e-commerce simples, uma plataforma médica possui domínios extremamente sensíveis e interdependentes (como Prontuário, Prescrição e Histórico), mas que exigem isolamento para evitar falhas em cascata.

Monólito Tradicional vs. Microfrontends vs. Monólito Modular

  1. Monólito Tradicional (Big Ball of Mud):

    • Problema: Tudo está misturado. Mudar o CSS de um botão no agendamento quebra a visualização do prontuário.
    • Saúde: Inaceitável devido ao alto risco de regressões clínicas.
  2. Microfrontends (Module Federation):

    • Problema: Complexidade operacional altíssima, perda de tipagem forte entre módulos e dificuldades de orquestração de estado global.
    • Saúde: Pode ser necessário em escalas globais, mas introduz latência e fragmentação.
  3. Monólito Modular (Nossa Escolha):

    • Solução: Uma única base de código (Monorepo) com fronteiras físicas e lógicas rígidas (Domínios).
    • Vantagem: Mantemos a tipagem de ponta a ponta (TypeScript), facilitamos refatorações em massa e garantimos o isolamento através de regras de dependência.

Pilares do Monólito Modular

1. Contextos Delimitados (Bounded Contexts)

Cada domínio de saúde (ex: Consultation) opera dentro de sua própria fronteira. Ele possui seu próprio dicionário de termos (Linguagem Ubíqua) e suas próprias regras de validação. Isso impede que a complexidade de um módulo "vaze" para os outros.

2. Baixo Acoplamento e Alta Coesão

  • Baixo Acoplamento: Domínios não se conhecem. Eles se comunicam via eventos de domínio. Se o módulo de Chat for removido, o Medical Record continua funcionando perfeitamente.
  • Alta Coesão: Tudo o que pertence à Teleconsulta (UI, Estado, Sagas, Máquina de Estado) reside dentro da pasta do domínio consultation.

3. Governança via Tooling

Para evitar que o "Monólito Modular" se transforme em um "Monólito Tradicional" com o tempo, utilizamos ferramentas (ESLint/NX) que barram importações proibidas em tempo real. Se um desenvolvedor tentar importar um Reducer de Scheduling dentro de Prescription, o sistema não compilará.

Benefícios para o Ecossistema Médico

  1. Refatoração Segura: Ao mudar o formato de um ID de paciente no pacote contracts, o TypeScript apontará instantaneamente todos os lugares em todos os aplicativos e domínios que precisam ser corrigidos.
  2. Performance Preditiva: Através do Lazy Loading, o navegador só baixa o código de domínios específicos quando o médico ou paciente os acessa.
  3. Caminho para Microfrontends: Se um domínio específico (ex: Exams) crescer demais e precisar de um time e deploy independentes, a migração para Microfrontend é trivial, pois as fronteiras de domínio já estão estabelecidas.

O Monólito Modular nos permite mover rápido como uma startup, mas com o rigor e a segurança exigidos por uma infraestrutura de saúde crítica.