Squad Front

Appearance

RFC 001: Arquitetura de Módulos Isolados (Modular Monolith) ​

  • Status: Draft
  • Autor: Charleston Anjos
  • Data: 2026-02-19
  • Escopo: Arquitetura Core do Ecossistema de Saúde

1. Resumo (Summary) ​

Esta RFC propõe a adoção de uma arquitetura de Monólito Modular baseada em Domain-Driven Design (DDD) para o novo ecossistema de saúde digital. A solução visa suportar mais de 100 milhões de usuários distribuídos nos 26 estados brasileiros, garantindo isolamento de falhas, escalabilidade de times e performance extrema em dispositivos de baixo custo através de Injeção Dinâmica e Comunicação Baseada em Eventos.

2. Motivação (Motivation) ​

O desafio de atender a uma população de nível nacional (100M+ pessoas) exige uma arquitetura que resolva os seguintes problemas críticos identificados:

  • Complexidade Crescente: Sistemas de saúde tendem a se tornar "Bolas de Lama" (Big Ball of Mud) onde mudanças no agendamento quebram o prontuário.
  • Latência e Performance: Usuários em regiões remotas com conexões 3G instáveis não podem carregar bundles gigantescos.
  • Risco Clínico e Jurídico: A falta de controle de fluxo pode levar a estados impossíveis (ex: finalizar consulta sem diagnóstico).
  • Conflitos de Desenvolvimento: Múltiplos times trabalhando no mesmo código causam gargalos de deploy e merge.

3. Proposta Técnica (Technical Proposal) ​

A arquitetura será estruturada em um Monorepo com as seguintes camadas e responsabilidades:

3.1. Estrutura de Camadas ​

  • Apps: Orquestradores leves (Entry Points) para diferentes perfis (Médico, Paciente, Admin).
  • Modules: Unidades de negócio isoladas (Bounded Contexts) contendo sua própria Store (Redux), Efeitos (Sagas) e UI.
  • Shared: Design System e utilitários agnósticos ao negócio.
  • Core: Infraestrutura técnica (Event Bus, Injetores, WebRTC, WebSocket).
  • Contracts: Única fonte de verdade para tipagem TypeScript e contratos de eventos.

3.2. Mecanismos de Isolamento ​

  • Injeção Dinâmica: Uso de useInjectReducer e useInjectSaga para carregar lógica apenas sob demanda.
  • Domain Events: Comunicação indireta entre módulos via Pub/Sub para evitar acoplamento lateral.
  • Boundaries: Imposição de regras de importação via ESLint/NX (ex: Módulo A não importa do Módulo B).

3.3. Segurança de Processo ​

  • State Machines (XState): Uso obrigatório para fluxos críticos de atendimento para garantir conformidade com protocolos médicos.

4. Impactos e Riscos (Impact & Risks) ​

  • Curva de Aprendizado: Desenvolvedores precisarão se adaptar aos padrões de Redux-Saga e XState.
  • Boilerplate: A criação de um novo módulo exige uma estrutura de pastas rigorosa (mitigado por geradores de código/scaffolding).
  • Complexidade de Debugging: O rastreio de fluxos baseados em eventos exige ferramentas de telemetria e observabilidade robustas (previstas no Roadmap).

5. Alternativas Consideradas (Alternatives) ​

  • Microfrontends (Module Federation): Descartado inicialmente devido à complexidade operacional e perda de Type Safety entre deploys independentes. A proposta atual é "MFE-Ready".
  • React Context: Descartado para lógica de negócio devido a problemas de performance de re-renderização em escala de 100M.

6. Plano de Rollout (Rollout Plan) ​

  1. Fase 1: Implementação do Core (Injetores e Event Bus).
  2. Fase 2: Migração dos domínios piloto (Agendamento e Autenticação).
  3. Fase 3: Implementação do Atendimento Online com XState.
  4. Fase 4: Auditoria de performance simulando carga nacional.

7. Conclusão ​

Esta proposta estabelece as bases para um sistema resiliente, escalável e seguro, capaz de sustentar a transformação digital da saúde no Brasil nos próximos anos.