Estrutura do Monorepo e Camadas (Health-Centric)

A organização física e lógica de pastas reflete a nossa estratégia de isolamento e reutilização. Cada camada possui uma fronteira tecnológica e funcional clara, essencial para manter a estabilidade de portais de saúde que crescem continuamente.

Estrutura de Pastas do Monorepo

O monorepo é organizado sob o diretório principal, separando o que é produto final (apps/) do que são módulos de negócio e infraestrutura (packages/).

root/
├── apps/                # Entry Points das Aplicações (ex: apps React/Vite)
│   ├── app-medical/     # Interface do Médico (Teleconsulta, Prontuário)
│   ├── app-patient/     # Interface do Paciente (Agendamentos, Histórico)
│   └── app-admin/       # Gestão Administrativa e Saúde Populacional
│
├── packages/
│   ├── modules/         # Módulos com Lógica de Negócio (Bounded Contexts)
│   │   ├── consultation/ # Lógica de Atendimento e Teleconsulta
│   │   ├── medical-record/ # Gestão de Prontuários e Prescrições
│   │   ├── vaccination/  # Gestão de Carteira de Vacinação
│   │   ├── scheduling/   # Agendamento de Consultas e Exames
│   │   ├── chat/         # Mensageria entre Médico e Paciente
│   │   └── users/        # Autenticação e Perfis de Usuários
│   │
│   ├── shared/          # Recursos Transversais Agnósticos a Módulo
│   │   ├── ui/          # Design System (Componentes Atômicos Médicos)
│   │   ├── hooks/       # Hooks de utilidade (ex: geolocalização, sensores)
│   │   └── utils/       # Helpers matemáticos e formatação (ex: CID, CPF)
│   │
│   ├── core/            # Infraestrutura Técnica (Base da Arquitetura)
│   │   ├── api/         # Configurações globais de HTTP/Axios
│   │   ├── websocket/   # Protocolo de sinalização em tempo real
│   │   ├── videocall/   # Adaptadores para SDKs de Vídeo (ex: WebRTC)
│   │   └── domain-events/ # Barramento central de eventos assíncronos
│   │
│   └── contracts/       # Tipos, Interfaces e Esquemas (DTS/Zod)

Camadas e Responsabilidades Detalhadas

1. Camada de Aplicação (Apps)

As aplicações são meras orquestradoras. Sua única função é configurar o ambiente (variáveis de ambiente, roteamento global, temas) e compor os módulos necessários. Elas não devem conter regras de validação médica ou cálculos complexos.

• Exemplo: O app-medical importa o componente de Teleconsulta do domínio de consultation e o injeta em uma rota protegida.

2. Camada de Módulos (Modules)

É o local mais importante da arquitetura. Cada módulo representa uma fatia funcional do negócio de saúde. Um módulo deve ser capaz de funcionar "sozinho" se todas as suas dependências de core e shared forem atendidas.

• Fronteira: Um módulo nunca importa nada de outro módulo. A troca de dados é feita via eventos.
• Componentização Interna:
  • api/: Funções de serviço que comunicam com o Backend.
  • store/: Estado global do módulo (Redux) injetado dinamicamente.
  • machines/: Lógica de transição de status (ex: Ciclo de vida da consulta).
  • ui/: Componentes visuais inteligentes que conhecem o módulo.

3. Camada de Shared (Compartilhados)

Contém blocos de construção básicos que não têm ideia de que estão em um sistema médico. Um botão aqui é apenas um botão, sem saber se será usado para "Salvar Prontuário" ou "Sair". Isso garante que o Design System seja puro e reutilizável.

4. Camada de Core (Núcleo)

Fornece o "encanamento" tecnológico. Se decidirmos trocar a biblioteca de comunicação via WebSocket ou o adaptador de Vídeo, fazemos a alteração aqui, e todos os módulos que utilizam esses recursos em packages/core serão atualizados automaticamente, mantendo a consistência técnica.

5. Camada de Contracts (Contratos)

Fundamental para o "Type Safety" (Segurança de Tipagem). Contém os schemas que definem como os dados transitam entre o Frontend e o Backend. O uso de Zod ou TypeScript puro aqui garante que se o Backend mudar o formato de um objeto de "Receituário", o erro seja detectado imediatamente durante a compilação do Frontend.