76 lines
4.7 KiB
Markdown
76 lines
4.7 KiB
Markdown
# 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.
|