Saltar a contenido

ADR 008: Dominio de negocio como plugin independiente

Estado

Aceptado — 2026-07 · Implementado (convención y catálogo)

Relacionado con ADR 001 (capas HIVE), ADR 017 (datos por plugin), ADR 023 (runtime SPI) y ADR 024 (límites entre dominios).

Contexto

En la numeración temprana de ADRs, el 008 se tituló «módulo booking» porque el primer dominio transaccional del PMV era reservas. En ese momento aún no estaba formalizada la regla: todo dominio de negocio es un plugin Independiente con repo, wheel pip, documentación y persistencia propios.

Eso generó confusión: lectores interpretaban el 008 como spec de booking en docs/adr/, cuando booking — como cualquier otro dominio — vive en su repo (cortex-plugin-booking) y en el catálogo de plugins.

Decisión

  1. Segmentación obligatoria: cada capacidad de negocio (reservas, clientes, pagos, facturación, …) es un plugin con entry point cortex.plugins, no código en cortex_framework.
  2. Framework sin dominio: core/ y framework/ exponen SPI, loader, IO, auth y paneles generativos; cero modelos, rutas REST ni tools MCP de un vertical concreto.
  3. Documentación canónica por plugin: spec en plugins/<id>/docs/ del repo del plugin (en el monorepo: plugins/<id>/); en el sitio público: docs/plugins/<id>/ (catálogo + enlaces). Los ADR de plataforma no duplican reglas de negocio.
  4. Integración entre dominios: solo HTTP (/api/v1/{namespace}) y events nombrados (ADR 021); sin imports cortex_plugin_* cruzados (ADR 024).
  5. Casos de uso: un vertical (p. ej. Reservas) ensambla plugins en products/* y docs/casos-de-uso/ (ADR 025); el loader no lee esa composición en runtime.

Ejemplo ilustrativo (no es el alcance de este ADR)

Plugin Spec canónica Rol
booking design.md Reservas multi-recurso
clients dependencies.md Dueño de client_ref
payments events.md Cobros; listener booking.confirmed

Los diagramas históricos numerados 008-modulo-booking-* en docs/diagrams/adr/ describen el dominio booking; la decisión de plataforma de este ADR es la segmentación en plugins, no el modelo de reservas.

Consecuencias

  • Positivas: frontera clara plataforma vs dominio; wheels y equipos por plugin; catálogo descubrible.
  • Negativas: más repos y contratos HTTP/events que mantener; migración de scaffolds antiguos a «plugin real» (ADR 023).

Referencias