Pular para o conteúdo principal

ADR 0001 — Visão geral da arquitetura

Introdução ao documento​

Registro de Decisão de Arquitetura (ADR) que documenta as decisões arquiteturais fundamentais do sistema hsl-lean-nas-emergencias.

Versionamento​

  • Versão: 1.0.0
  • Data: 2026-03-10
  • Autores: Equipe HSL / Weef Interativa

Referencial teórico​

Status​

Aceita — Arquitetura em produção.

Contexto​

O Hospital Sírio-Libanês (HSL) precisava de uma plataforma comunitária para o programa "Lean nas Emergências", conectando hospitais brasileiros para melhoria de processos em emergências. Requisitos:

  1. Comunidade online com grupos por hospital.
  2. Coleta de indicadores (KPIs) diários, mensais e semestrais.
  3. Biblioteca de materiais acadêmicos e técnicos.
  4. Fóruns de discussão técnica.
  5. Sistema de cursos (EAD) com certificação.
  6. Gestão de eventos presenciais.
  7. Integração com Canvas LMS para ensino a distância.

Decisão​

WordPress com BuddyPress como plataforma base​

  • Escolha: WordPress 6.x + BuddyPress + BBPress.
  • Motivação: Plataforma de comunidade madura, com gestão de usuários, grupos, fóruns e extensibilidade via plugins e tema customizado.
  • Alternativas descartadas: Plataforma custom (custo/prazo), Discourse (sem integração WP nativa), Moodle (focado demais em LMS).

Evidência: style.css:1-5 — tema "Lean nas Emergências 5.2" por Weef Interativa.

Hospitais como BuddyPress Groups​

  • Escolha: Cada hospital é um BP Group com metadados customizados (CNES, endereço, KPI config).
  • Motivação: Reuso da infraestrutura de membros/permissões do BP. Administradores de grupo gerenciam seu hospital.
  • Trade-off: Dependência forte do BuddyPress; migração futura seria complexa.

Evidência: theme/functions/helpers/hospitals_groups.php — groups_get_groupmeta() com meta keys hospital_*.

Banco de dados separado para KPIs​

  • Escolha: MySQL database kpi separado do banco WordPress, com tabelas coleta, dados_coleta, tipo_coleta.
  • Motivação: Isolamento de dados críticos de indicadores. Possibilidade de consultas pesadas sem impactar o WP.
  • Trade-off: Adiciona complexidade de gestão (duas conexões, backup separado, schema não versionado).

Evidência: wp-config.php:81-88 — constantes DB_KPI_*. mysql-init/init.sql — CREATE DATABASE kpi.

Canvas LMS como plataforma EAD​

  • Escolha: Integração via REST API do Canvas para criação de usuários, cursos e matrículas.
  • Motivação: Reuso de plataforma LMS robusta, evitando implementar funcionalidade de cursos internamente.
  • Trade-off: Dependência de serviço externo. Token de API armazenado no banco (ACF Options).

Evidência: theme/functions/ead/ead.php — chamadas REST para accounts/{id}/users e courses/{id}/enrollments.

ACF Pro para campos customizados​

  • Escolha: Advanced Custom Fields Pro para todos os campos adicionais (posts, options, grupos).
  • Motivação: Produtividade no desenvolvimento, UI admin intuitiva, integração com templates.
  • Trade-off: Dependência de plugin comercial. Campos definidos no banco (sincronização JSON não versionada).

Evidência: theme/functions.php — uso extensivo de get_field(), update_field().

Docker Compose para ambiente de desenvolvimento​

  • Escolha: docker-compose.yml com serviços wordpress (PHP 8.3-Apache) e db (MySQL 8.0).
  • Motivação: Ambiente local replicável sem dependências de sistema.
  • Trade-off: Sem orquestração em produção — deploy manual via All-in-One WP Migration.

Evidência: docker-compose.yml, Dockerfile.

Módulo de cadastro custom (substituindo Gravity Forms)​

  • Escolha: Módulo em theme/functions/registration/ com Handler, Validator, Sanitizer e User Service.
  • Motivação: Controle total sobre validações, UX e integração com BuddyPress Signups.
  • Trade-off: Mais código a manter vs. plugin de formulário.

Evidência: theme/functions/registration/class-registration-handler.php — 228 linhas.

Consequências​

Positivas​

  • Plataforma funcional e extensível com ecossistema WordPress maduro.
  • Comunidade hospitalar com gestão descentralizada (cada hospital gerencia seu grupo).
  • KPIs isolados do WordPress, permitindo consultas analíticas independentes.
  • EAD delegado para plataforma especializada (Canvas).

Negativas​

  • Forte acoplamento com BuddyPress — migração ou upgrade major seria custosa.
  • Schema do banco KPI não versionado — risco de drift.
  • Sem testes automatizados — regressão não detectada.
  • Campos ACF definidos no banco — difícil rastrear mudanças.
  • Sem healthchecks ou observabilidade formal.

Pendências​

  • Versionar schema completo do banco KPI (migrations).
  • Adicionar testes unitários/integração.
  • Exportar campos ACF para JSON versionado.
  • Implementar healthchecks no Docker Compose.