Governança e Escalabilidade em Sistemas de Saúde

A integridade arquitetural de um sistema que lida com dados de saúde de mais de 100 milhões de brasileiros, distribuídos por todos os 26 estados, é fundamental. Conforme o projeto cresce para incluir novos domínios (ex: Agendamento, Vacinação, Farmácia, Laboratório) e lidar com as particularidades regionais e regulatórias de cada estado, precisamos de mecanismos automáticos que impeçam o aumento da complexidade desordenada e garantam a performance extrema exigida por essa escala nacional.

Fronteiras Arquiteturais (Architectural Boundaries)

Utilizamos ferramentas como ESLint (regras de importação) ou NX Boundaries para impor regras de dependência que são validadas em tempo real e no CI/CD.

Regras de Ouro de Dependência

1. Isolamento de Módulos: Um arquivo em packages/modules/consultation nunca deve importar nada de packages/modules/chat.
   • Por que?: Para garantir que se o módulo de Chat for removido ou substituído, o módulo de Consultas não sofra nenhum impacto colateral. A comunicação deve ser SEMPRE via Domain Events.
2. Unidirecionalidade Rigorosa:
   • Apps -> Modules -> Shared -> Core -> Contracts.
   • O Core nunca deve importar nada de um Domain.
   • O Shared nunca deve importar nada de um Domain.
3. Encapsulamento via Public API: Cada pacote deve exportar apenas o que é estritamente necessário através de seu arquivo index.ts. Componentes internos, reducers específicos ou helpers de domínio não devem estar visíveis para quem consome o pacote.

Escalabilidade para Múltiplos Times

O isolamento por módulos (Bounded Contexts) permite que a organização escale horizontalmente:

• Desenvolvimento em Paralelo: Um time pode refatorar completamente a lógica de Prescrição Médica sem causar conflitos de mesclagem (merge conflicts) com o time que está trabalhando no Agendamento.
• Propriedade de Código (Code Ownership): Times diferentes podem ser "donos" de pacotes específicos no monorepo, facilitando a revisão de código e a governança.
• Testes Focados: Podemos rodar testes apenas para os módulos que sofreram alteração, reduzindo o tempo de pipeline e acelerando o feedback para os desenvolvedores.

Visão de Futuro: De Monólito Modular para Microfrontends

A arquitetura atual foi projetada como um Modular Monolith propositalmente. No estágio atual, o monorepo oferece a melhor experiência de desenvolvimento, com tipagem forte de ponta a ponta e facilidade de refatoração.

No entanto, estamos preparados para o futuro:

• Evolução para Microfrontends: Como os módulos já são isolados, possuem injeção dinâmica de estado e se comunicam via eventos, a migração para uma solução de Module Federation é quase trivial. Cada módulo em packages/modules/* pode se tornar um micro-app independente, hospedado em um bucket próprio e carregado em runtime.
• Independência de Deploy: No futuro, o time de "Exames" poderá fazer deploy de uma correção sem precisar gerar um novo bundle para o "Portal do Médico" inteiro.

Esta estratégia garante que o sistema de saúde seja robusto hoje e flexível para os desafios de amanhã.