Nota de arquitectura
Información y decisión: dos capas
Contexto de arquitectura
Método reutilizable
Aplicado en
Durante un tiempo, la arquitectura trató la creación de un documento como si fuera el final de un proceso.
Era una simplificación útil. También era incorrecta.
Un documento puede registrar, comunicar o demostrar algo. La consecuencia — aprobar, pagar, publicar o rechazar — pertenece al proceso que lo utiliza. Confundir ambos hace que un sistema parezca completo antes de que la decisión importante haya ocurrido realmente.
La diferencia parece pequeña. En la práctica, cambia dónde deben situarse la validación, la autoridad, el juicio humano y la recuperación ante fallos.
Dónde falló el modelo
El problema se hizo visible en una integración contable. La secuencia prevista era prudente: preparar información en un sistema, revisarla y solo entonces permitir una acción externa con consecuencias fiscales.
La documentación pública de la interfaz no permitía demostrar inicialmente que existiera una pausa significativa antes de la finalización. Parecía haber varias implementaciones posibles, pero ninguna estaba verificada.
Esa incertidumbre definió el primer límite de producción. El sistema podía cargar los datos locales autorizados, comprobar permisos y coherencia, preparar la referencia externa e indicar si la información estaba lista. No podía escribir en el sistema externo.
No era automatización incompleta disfrazada de arquitectura. Era un límite explícito: avanzar con lo conocido y detenerse donde el contrato externo seguía siendo incierto.
El error vino después. Convertí un control diseñado para una integración con consecuencias en un modelo general para todos los documentos.
El modelo no se adaptaba bien a otros casos. Un contrato, un informe operativo, un extracto importado y una nota interna son documentos, pero no crean las mismas obligaciones ni exigen los mismos controles.
El caso era una prueba útil. No era la categoría.
Dos responsabilidades, no un único ciclo de vida
El modelo revisado separa dos responsabilidades.
La primera es la propia información:
- ¿Qué es este objeto?
- ¿Cuál es la versión actual?
- ¿De dónde procede la información?
- ¿Quién puede acceder a ella o modificarla?
- ¿Durante cuánto tiempo debe conservarse?
La segunda es la decisión que la utiliza:
- ¿Quién tiene autoridad para avanzar?
- ¿Qué debe comprobarse primero?
- ¿Qué acontecimiento crea la consecuencia real?
- ¿Qué ocurre si el resultado es rechazado o permanece incierto?
- ¿Cómo confirmamos lo que hizo realmente un sistema externo?
Las dos capas se relacionan, pero no avanzan juntas. Un contrato puede llegar a su cuarta versión mientras la revisión jurídica sigue abierta. Un informe puede ser definitivo como registro mientras la decisión operativa basada en él continúa pendiente. Un PDF puede conservar la prueba de una aprobación sin ser la aprobación misma.
Esta separación es coherente con normas consolidadas de gestión documental y de procesos. ISO 15489 se centra en la creación y gestión de registros. W3C PROV distingue información, actividad y responsabilidad. BPMN separa los datos utilizados por un proceso de las actividades y decisiones que forman parte de ese proceso.
Las normas validan la distinción. No necesitan dominar el diseño.
Qué cambió en la arquitectura
El primer modelo parecía tranquilizadoramente lineal: la información entraba, pasaba por la validación, recibía aprobación y producía un documento final.
El trabajo real era menos ordenado. Una decisión podía quedar en espera, fallar, volver para ser corregida o depender de una respuesta externa que nunca llegaba. El documento podía cambiar sin reabrir la decisión; la decisión podía cambiar sin producir un archivo nuevo.
La arquitectura revisada comienza, por tanto, con tres preguntas:
- ¿Qué información debe seguir siendo fiable?
- ¿Qué decisión crea la consecuencia y quién es responsable de ella?
- ¿Qué prueba y recuperación son necesarias cuando el resultado es incierto?
Los controles dependen de las respuestas. Una doble aprobación puede estar justificada ante un riesgo y ser innecesaria en otro contexto. Una firma puede demostrar quién firmó sin probar que el contenido es correcto. Una repetición automática puede ser segura cuando el servicio externo evita duplicados y peligrosa cuando no lo hace. Conservar todas las versiones puede ayudar en una auditoría y, al mismo tiempo, contradecir una obligación legítima de eliminación.
El control no define la arquitectura. La arquitectura explica por qué existe el control y dónde deja de ser útil.
El cambio profesional
Las versiones anteriores de mi trabajo se volvían a menudo más elaboradas a medida que aumentaba la incertidumbre. Más estados, más comprobaciones y más componentes hacían que el diseño pareciera más seguro.
Este caso cambió ese instinto. Cuando una suposición no puede verificarse, añadir mecanismos a su alrededor no la convierte en verdadera. Un límite más pequeño puede ser el diseño más responsable.
Esta es la evolución que merece la pena mostrar: no una secuencia de funcionalidades entregadas, sino un cambio en la forma de distribuir la responsabilidad. La información debe seguir siendo comprensible. Las decisiones necesitan responsables. Las consecuencias deben ser observables. La incertidumbre debe detener el sistema en el punto correcto.
La madurez arquitectónica no se ve en el número de cajas de un diagrama. Se ve en la precisión de sus límites.
Fuentes
- TOConline, Documentos de Venta — API actual — https://api-docs.toconline.pt/apis/vendas/documentos-de-venda (consultado el 14 de septiembre de 2026).
- TOConline, Documentos de Venta — Versiones anteriores — https://api-docs.toconline.pt/apis/versoes-anteriores/vendas/documentos-de-venda (consultado el 14 de septiembre de 2026).
- ISO, ISO 15489-1:2016 — Records management: Concepts and principles — https://www.iso.org/standard/62542.html (versión actual confirmada por ISO en 2021).
- W3C, PROV-O: The PROV Ontology — https://www.w3.org/TR/prov-o/ (Recomendación del W3C, 2013).
- Object Management Group, Business Process Model and Notation 2.0.2 — https://www.omg.org/spec/BPMN/2.0.2/PDF (2014).
- IETF, RFC 9110 — HTTP Semantics, §9.2.2 Idempotent Methods — https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2 (2022).
- Unión Europea, Reglamento (UE) 2016/679 — RGPD, artículo 5.º(1)(e) — https://eur-lex.europa.eu/eli/reg/2016/679/oj.