Pular para o conteúdo principal

ADR 0001 - Visao de Arquitetura Atual

  • Status: Aceito (estado atual do codigo)
  • Data: 2026-02-12

Contexto

O repositorio implementa backend de negocio sobre WordPress, com a maior parte da logica no tema we-dhedalos.

Evidencias diretas no codigo:

  • rotas REST customizadas em we-dhedalos/functions/rest/**,
  • dominio modelado via CPT + ACF em post_types, taxonomies, acfs,
  • integracoes externas (SimplyBook, 8x8/Jitsi, Novu, API agenda, API submissions),
  • runtime containerizado (Nginx + PHP-FPM + MariaDB + Redis),
  • deploy via Helm/Kubernetes acionado no CI/CD.

Decisao

Manter arquitetura orientada a WordPress com os seguintes pilares:

  1. WordPress como runtime principal de API e persistencia.
  2. Tema we-dhedalos como modulo de dominio (API, regras, integrações, cron).
  3. Infra containerizada padrao para ambientes local e Kubernetes.
  4. API principal no namespace dhedalos/v1 com prefixo REST /api.

Consequencias

Positivas

  • Alto reaproveitamento de capacidades nativas do WordPress (CPT, meta, WP_Query, WP REST).
  • Evolucao incremental sem camada adicional de servico externo.
  • Operacao alinhada ao ecossistema já utilizado pelo time.

Negativas

  • Acoplamento funcional ao tema (dificulta reutilizacao isolada do dominio).
  • Fronteiras arquiteturais menos explicitas (dominio x aplicacao x integração).
  • Maior risco de divergencia de contrato API sem governanca central.
  • Autorizacao dispersa em callbacks de rota e logica interna.

Decisoes derivadas

  • Prefixo REST customizado /api deve ser tratado como contrato operativo em documentacao e consumidores.
  • Endpoints de servico devem usar Authorization: Svc <token>.
  • Fluxos que dependem de sessao devem explicitar is_user_logged_in e regras de role.

Alternativas consideradas

Nao ha registro de alternativas formais no repositorio (ex.: plugin de dominio separado, microservico dedicado, BFF independente).

Pendencias

  • Definir estrategia formal para desacoplamento progressivo da camada de dominio do tema.
  • Definir padrao de versionamento semantico de contratos REST alem de dhedalos/v1.
  • Definir baseline de seguranca para novas rotas (authn/authz, observabilidade, limites e paginação).