Visão Geral da Arquitetura (Saúde Digital)

Esta documentação detalha a arquitetura do ecossistema de aplicações voltadas para o setor de saúde, projetada para servir a uma escala de mais de 100 milhões de usuários e presente nos 26 estados brasileiros. Baseada em princípios de Modular Monolith, Domain-Driven Design (DDD) e Monorepo, a estrutura foi pensada para suportar alta escalabilidade, isolamento de domínios sensíveis e uma evolução fluida para microfrontends em cenários de telemedicina complexos de nível nacional.

O projeto utiliza uma estratégia de monorepo para gerenciar múltiplas aplicações (Portal do Médico, Portal do Paciente e Painel Administrativo) e pacotes compartilhados, garantindo consistência técnica, segurança de dados e alto reaproveitamento de componentes entre diferentes produtos.

Contexto de Negócio: Ecossistema Médico

Diferente de aplicações genéricas, sistemas de saúde exigem um rigor extremo quanto à integridade dos dados e o isolamento de fluxos. Um erro no domínio de Prontuário Eletrônico não deve impactar a disponibilidade do domínio de Carteira de Vacinação ou Vídeo. Nossa arquitetura reflete essa necessidade de resiliência através de módulos independentes que operam em harmonia.

Exemplos de Aplicações do Ecossistema

• App Medical: Focado na jornada do profissional de saúde, incluindo gestão de agenda, realização de teleconsultas e edição de prontuários.
• App Patient: Focado na experiência do paciente, permitindo agendamento de consultas, visualização de carteira de vacinação e comunicação direta com a clínica.
• App Admin: Gestão de credenciamento de médicos, auditoria de logs de acesso e dashboards de saúde populacional.

Princípios Fundamentais

A arquitetura é regida por cinco pilares que garantem a sustentabilidade do código a longo prazo:

• Isolamento de Módulo (Bounded Contexts): Cada módulo de negócio (ex: Consultas, Chat, Usuários) é autocontido. Ele possui sua própria lógica, estado global (Redux), efeitos colaterais (Saga) e interfaces, expondo apenas o estritamente necessário para o mundo externo.
• Dependência Unidirecional e Rigorosa: O fluxo de dependências segue uma hierarquia clara. Camadas superiores podem consumir as inferiores, mas nunca o contrário. Isso elimina acoplamentos circulares que tornam o sistema frágil e difícil de testar.
• Comunicação Desacoplada via Domain Events: Interações entre módulos nunca ocorrem por importação direta de lógica. Se o módulo de Agendamento precisa notificar o módulo de Chat sobre uma nova consulta, ele publica um evento. O Chat, como assinante, decide como reagir.
• Injeção Dinâmica de Recursos (Dynamic Injection): Recursos de estado e lógica pesada são carregados apenas quando o usuário entra no contexto específico (ex: o código do módulo de prescrição médica só é baixado e injetado na memória quando o médico inicia um atendimento).
• Orquestração de Fluxos com Máquinas de Estado: Para processos críticos onde "estados impossíveis" podem causar riscos clínicos (ex: finalizar uma consulta que ainda não foi iniciada), utilizamos o XState. Isso garante que o software siga exatamente o protocolo médico definido.

---

Este documento serve como a verdade única sobre como construímos software de alta qualidade para o setor de saúde.