Plataforma técnica · Orchestrator

Command (Bounded Context)

Orchestrator Command Admin

Command es el bounded context que opera la plataforma SaaS: provisiona tenants, vigila sesiones activas, expone el dashboard ejecutivo y administra el catálogo canónico (manual y plan de cuentas template) que se distribuye a cada tenant.

Vive en orchestrator/src/domain/command/ y se expone bajo prefijos /api/tenant*, /api/sessions, /api/command/* y /api/monitoring. Acceso restringido a roles SUPER_ADMIN y ADMIN.

Mapa del Dominio

flowchart LR
  subgraph CLI["Super Admin (Sevastopol islands)"]
    UI["Command Center"]
  end

  subgraph CMD["domain/command/"]
    direction TB
    T["TenantService"]
    S["SessionService"]
    M["MonitoringService"]
    MC["manual-cuentas/<br/>ManualCuentasService"]
    PCS["plan-cuentas-sync/<br/>PlanCuentasSyncService"]
  end

  subgraph PG[("PostgreSQL · nostromo_command")]
    TT["command.tenants"]
    VTI["command.v_tenant_info"]
    AUS["auth.user_sessions"]
    VDS["monitoring.v_dashboard_summary"]
  end

  subgraph MG[("MongoDB · nostromo_manual")]
    CUE["cuentas"]
  end

  subgraph TPL[("PostgreSQL · accounting_template")]
    PCT["plan_contable"]
  end

  subgraph TNT[("PostgreSQL · nostromo_&lt;rut&gt; (cada tenant)")]
    PCN["plan_contable"]
  end

  UI --> T & S & M & MC & PCS
  T --> TT & VTI
  S --> AUS
  M --> VDS
  MC --> CUE
  MC -. valida códigos .-> PCT
  PCS <-->|diff &amp; sync| PCT
  PCS -->|propaga| PCN

Subdominios

Tenants Provisionamiento y ciclo de vida de empresas. CRUD sobre command.tenants y creación de la base de datos por-tenant.

Sessions Sesiones activas en tiempo real, kill switch (DELETE /api/sessions/:id) y métricas de uptime por usuario.

Monitoring Dashboard Resumen ejecutivo: tenants, usuarios activos, sesiones, salud del sistema (CPU/RAM/Disco). Mezcla DB + systeminformation.

Manual de Cuentas Catálogo canónico contable en MongoDB. Edición de documentación de cuentas (asientos tipo, NIC/IFRS, ejemplos).

Plan de Cuentas Sync Diff y sincronización del plan template (accounting_template) contra cada tenant. Promote, propagate, dry-run.

Por qué este bounded context existe

Necesidad operacional	Servicio responsable
”Necesito dar de alta una empresa nueva.”	`TenantService` + `tenant-db.ts`
”Hay un usuario sospechoso conectado, sácalo.”	`SessionService.terminateSession`
”¿Cómo está el sistema?” (CEO dashboard)	`MonitoringService.getSummary`
”Falta documentación para la cuenta 1101030.”	`ManualCuentasService.save`
”Agregamos una cuenta nueva al template, propágala a todos.”	`PlanCuentasSyncService.createCuentaInTemplate({ propagate: true })`
”Tenant X tiene cuentas que no están en template — ¿son locales o huérfanas?”	`PlanCuentasSyncService.getDiff`

Relación con otras capas

api/endpoints/: contratos HTTP de estos servicios documentados en Command Center API y Auth y Sesión API.
services/: los servicios de dominios de negocio (payroll, activo-fijo, etc.) no viven aquí — son bounded contexts separados.
observabilidad/: el sistema de audit log y métricas Prometheus es infraestructura cross-cutting (middleware en lib/audit.ts y middleware/metrics.ts), distinta del MonitoringService que solo lee dashboards.
agentes: el registry de agentes (/api/agent/registry, /api/agent/tasks) se documenta como parte de Command Center API. Se enruta bajo routes/command/ por conveniencia administrativa pero vive en services/agent/, fuera del dominio Command.

Bases de datos involucradas

Base	Pool	Schemas/Colecciones consumidos
`nostromo_command`	`centralPool`	`command.tenants`, `command.v_tenant_info`, `auth.user_sessions`, `monitoring.v_dashboard_summary`
`accounting_template`	`getTenantPool('accounting_template')`	`plan_contable` (template canónico)
`nostromo_<rut>`	`getTenantPool(db)`	`plan_contable` por tenant (sync destino)
`nostromo_manual`	`getManualDb()` (MongoDB)	`cuentas` (documentación contable)

Autorización

Todos los endpoints del dominio Command están protegidos por authenticateToken + authorizeRoute. Las operaciones destructivas (PUT/DELETE de tenants, terminate session, delete cuenta del template) verifican adicionalmente req.user.role === 'SUPER_ADMIN' en el handler. Ver Auth y Sesión API para el contrato de roles.