# Arquitectura

Un único módulo Maven, paquete raíz `com.organizacion.orchestrator`. La implementación sigue la especificación; esta entrega establece sus fronteras, no implementa todavía el motor.

| Capacidad | Responsabilidad |
|---|---|
| flow | Borradores, validación, publicación, activación y caché inmutable |
| request | Instancias, acceso por recurso y eventos disponibles |
| execution | Comandos idempotentes, cola PostgreSQL, leases, fencing y recuperación |
| decision | AST tipado y decisiones puras con BigDecimal |
| action | Registro de handlers y mappings permitidos |
| integration | Catálogo confiable, HTTP y normalización de contratos |
| document | Referencias verificadas; sin almacenamiento binario |
| audit | Historial inmutable y auditoría administrativa |
| shared | Errores, identidad, reloj y configuración transversal |

Cada capacidad crecerá en `domain`, `application`, `infrastructure` y `api` cuando la tarea lo requiera. Dominio no depende de HTTP/JPA. API usa DTOs separados. Infraestructura implementa puertos. No crear entidades o interfaces ficticias para aparentar completar T04.

## Fronteras transaccionales

1. Aceptar un evento en transacción corta: acceso, bloqueo de solicitud, idempotencia, revisión, guardia, ejecución PENDING y auditoría.
2. Worker reclama con SKIP LOCKED y confirma antes de HTTP. Cada acción guarda checkpoint y clave externa estable.
3. Finalizar en transacción: validar lease/token/revisión, aplicar datos/estado y guardar resultado y auditoría atómicamente.

Una sola ejecución activa por solicitud. La incertidumbre de un efecto externo exige conciliación. No prometer exactly-once. Estados de ejecución y negocio son independientes.

## Configuración y acceso

Publicación inmutable; instancias fijan flow_id. Activo se resuelve coherentemente en PostgreSQL. JSONB extiende datos; no permite scripts, clases, URLs o credenciales arbitrarios. Cambios de licencia con capacidades existentes no requieren columnas ni condiciones Java específicas.

JWT se valida por firma, expiración, issuer y audiencia. T07 expone administración protegida y T08 creación/consulta de solicitudes. Roles, scope y propiedad se verifican antes de acceder a recursos; ambos grupos de rutas requieren habilitación explícita y runtime DB restringido. Sin entidades abiertas durante llamadas HTTP (`open-in-view=false`).

## Dominio implementado en T04

Consultar [modelo y puertos](DOMAIN_MODEL.md). El dominio y los puertos son Java
puro; los records contienen snapshots inmutables. flow/api/ValidationReportResponse
es un DTO separado con conversión explícita y prueba contra el esquema REST.
Los adapters JPA/HTTP y servicios de aplicación se implementarán en sus tareas;
ningún record del dominio es entidad JPA ni se expone automáticamente por REST.

## Administración interna de flujos T06

Consultar [validación y publicación](FLOW_PUBLICATION.md). FlowAdministration y sus
puertos son independientes de infraestructura. PostgresFlowStore implementa el
protocolo de locks/auditoría con JDBC transaccional (ADR-010). La exposición de
controladores administrativos queda ligada a T07, con autenticación/autorización
verificada; los contratos REST existentes no se modifican.


## Solicitudes T08

Requests y RequestStore mantienen la frontera pura de aplicación. PostgresRequestStore
comparte DataSource/transacción con FlowStore, serializa claves idempotentes en
PostgreSQL y confirma solicitud/auditoría/ledger en conjunto. RequestView es un DTO
explícito; su consulta usa un snapshot SQL para instancia, flujo fijado y ejecución
activa. Configuración de infraestructura común independiente del interruptor admin.
Detalles y decisiones: REQUESTS.md, SECURITY.md y ADR-012.

## Aceptación de eventos T09

Events/EventStore y EventPolicy conservan aplicación/dominio puros. PostgresEventStore
bloquea la solicitud autorizada y confirma ejecución, revisión y auditoría juntas.
El replay lee estado actual antes de revisar la revisión esperada; las acciones
permanecen sin ejecutar. La definición se obtiene por flow_id fijado, también tras
retiro, sin invertir el orden de locks de publicación. Ver EVENTS.md y ADR-013.

## Worker T10

WorkerStore separa reclamación, renovación, carga/checkpoints y confirmación atómica.
PostgresWorkerStore implementa fencing con tiempo DB. WorkerEngine resuelve mappings,
reutiliza decisiones T05 y valida datos finales. WorkerLoop limita concurrencia y
renueva durante acciones fuera de transacción. WorkerActions es el puerto para
adapters T11; el fallback no inventa resultados. ExecutionController expone una
proyección autorizada del estado. V3 conserva effect para recuperación segura.
Ver WORKER.md y ADR-014.