Perfil de arquitectura de software¶
Estado: propuesto. Este perfil concreta la propuesta optativa de ingeniería agnóstica. No cambia axiomas ni requisitos aceptados de ASILO, MILPA o SCAFFOLD y no impone una arquitectura universal. La elección se registra por sistema y se revisa frente a requisitos y atributos de calidad; un nombre de estilo no prueba que la implementación lo cumpla.
Declarar dimensiones independientes¶
La arquitectura de aplicación, la estructura del repositorio, el estilo de integración, el modelo de despliegue y el contexto regional son decisiones relacionadas, pero no intercambiables. Un proyecto puede ser un monolito modular en un monorepo, desplegado como contenedor en un VPS de una región determinada. No se debe inferir una dimensión a partir de otra.
| Dimensión | Valores ilustrativos | Qué decisión registra |
|---|---|---|
| Forma de aplicación | biblioteca/SDK, CLI, batch/worker, API, web, móvil, escritorio, sistema embebido/edge, sistema multiagente | entradas, límites, consumidores y efectos |
| Estilo estructural | monolito modular, capas, puertos y adaptadores, núcleo funcional, microservicios, orientado a eventos, pipeline, plugins | módulos, límites, dependencias y mecanismos de composición; pueden combinarse cuando se declara la relación |
| Repositorio | monorepo, multirepo, híbrido | propiedad, límites de paquetes, pruebas, versiones y cambios coordinados |
| Integración | síncrona request/response, eventos, colas, streams, archivos/lotes, llamadas locales | contratos, entrega, orden, idempotencia, reintentos y fallas parciales |
| Ejecución | proceso único, VM/VPS, contenedor, orquestador, PaaS, funciones administradas, edge, on-premises, híbrida o multi-cloud | unidad de despliegue, operación, disponibilidad, recuperación y portabilidad requerida |
| Datos | relacional/transaccional, documento, clave-valor, grafo, analítico, eventos/streams; sin persistencia | propietarios del dato, consistencia, retención, migración, recuperación y evidencia |
| Residencia | región/proveedor declarados, almacenamiento local, replicación, transferencias | clasificación, ubicación efectiva, copias, llaves y jurisdicciones que deben revisar personas competentes |
Los modelos relacional, documento, clave-valor, grafo, analítico y de eventos son opciones según consultas, consistencia, retención y operación; no se selecciona una base por defecto universal. Declara propiedad, migración, recuperación y residencia con evidencia pertinente. Un proyecto sin almacenamiento persistente registra esa condición y su razón.
Los términos se usan como descriptores, no como catálogo cerrado. Un descriptor desconocido se conserva como extensión del proyecto y requiere explicación; no se lo equipara silenciosamente con otro tipo.
Selección de estilo y topología¶
Empieza con el diseño más sencillo que satisfaga requisitos comprobables y mantenga límites de cambio claros. Un monolito modular es una opción inicial, no una regla. Considera microservicios cuando existan límites de dominio estables, despliegue o escalado realmente independiente, propiedad operativa clara y capacidad para asumir observabilidad distribuida, red, consistencia, seguridad entre servicios y operación de fallas parciales. No se eligen por moda, número de equipos o porque el repositorio tenga muchos paquetes.
Usa orientación a eventos cuando el desacoplamiento temporal, la carga o la integración lo justifiquen y se puedan declarar entrega, duplicados, orden, idempotencia, retención y recuperación. Un sistema de plugins requiere límites de confianza, versiones de contrato, procedencia, compatibilidad, permisos por capacidad y política de carga; descubrir un plugin no lo autoriza ni ejecuta. Capas, puertos/adaptadores y módulos son medios para hacer dependencias visibles, no garantías de seguridad.
Monorepo y microservicios son ejes ortogonales. Un monorepo puede contener varias unidades desplegables; varios repositorios pueden producir un monolito. El monorepo necesita propiedad por módulo, pruebas y builds selectivos reproducibles, reglas de dependencia y versionado explícito de interfaces. Multirepo necesita contratos publicados, compatibilidad, coordinación de cambios y trazabilidad de versiones. Evita ambas fragmentaciones cuando su costo supere el beneficio demostrado.
Nube, VPS y operación¶
«Nube» describe un modelo de servicio/operación; «VPS» describe una máquina virtual alquilada. Ninguno determina por sí solo la forma de la aplicación, la seguridad ni la jurisdicción. Para VPS declara responsable de parches, endurecimiento, acceso administrativo, firewall, backups probados, monitoreo, recuperación, capacidad, certificados y respuesta a incidentes. Para servicios administrados declara proveedor, región seleccionada, regiones de respaldo, subprocesadores relevantes, exportación y procedimiento de salida. En on-premises declara los responsables equivalentes.
Todo despliegue identifica componentes, límites de red y confianza, datos que fluyen, almacenes, secretos, puntos de efecto, dependencias externas, observabilidad, degradación, recuperación y reversión. Mantén configuración y secretos fuera de artefactos; concede permisos mínimos a identidades de carga. Los diagramas de contexto, contenedores y despliegue deben corresponder a versiones identificables de sus fuentes y alimentar el grafo de impacto.
Región y jurisdicción¶
La configuración regional de software es un perfil extensible de datos y operación: locales/formatos, idiomas, zona horaria, moneda, unidades, calendarios, formatos de dirección, formatos de identificadores y requisitos técnicos declarados. Debe poder componerse con un núcleo internacional y paquetes versionados. Los valores regionales son configuración/datos validados, no código ejecutado desde el paquete.
La región técnica seleccionada por un proveedor, el locale de la interfaz, la zona horaria y la jurisdicción aplicable son variables distintas. Ninguna determina automáticamente las otras. Residencia de datos, transferencias, obligaciones legales, consentimiento y plazos requieren fuentes con alcance y vigencia, contexto explícito y revisión competente. Si los paquetes regionales discrepan o falta evidencia, el estado es indeterminado/revisión requerida; no se escoge la regla más permisiva ni la más reciente sin autoridad.
Para México, los requisitos exclusivos se declaran en un paquete o perfil de jurisdicción versionado, con fuentes, autoridad, alcance, fecha de revisión, exclusiones, evidencia y responsable; no se incorporan al núcleo internacional. El perfil puede señalar dependencias técnicas como ubicación, retención, controles de acceso o exportación, pero no constituye asesoría ni determina aplicación legal. El diseño debe permitir añadir otros paquetes jurisdiccionales sin duplicar o mutar silenciosamente la arquitectura común.
Atributos de calidad, amenazas y preparación operativa¶
Cada arquitectura declara los atributos de calidad aplicables, su prioridad, objetivo medible, método de medición, responsable y evidencia. Selecciona los que importan: percentiles de latencia y carga, disponibilidad, RTO/RPO, accesibilidad, minimización de datos, límite de costo, portabilidad o mantenibilidad. Un valor sin carga, entorno y ventana de medición es una meta, no rendimiento verificado. Registra compensaciones y riesgos residuales.
La seguridad entra desde los requisitos y el modelo de amenazas, no sólo en una revisión final. Identifica activos, actores, fronteras de confianza, flujos de datos, abusos, dependencias, secretos y puntos de efecto. Aplica privilegio mínimo y comprueba identidad, recurso, acción y contexto vigente en cada frontera pertinente; estar dentro de una red o repositorio no concede confianza. La falta o invalidez de un control requerido falla cerrada. Pruebas de arquitectura y código pueden verificar fronteras declaradas, pero no demuestran ausencia de vulnerabilidades.
Cada despliegue declara responsable operativo y runbooks aplicables para respaldo/restauración, respuesta a incidentes, parches, rotación de llaves, monitoreo, revisión de accesos, capacidad y recuperación. Define SLO y umbrales cuando el servicio los necesite. VPS, nube, servicio administrado y on-premises tienen operadores distintos: no se infiere el responsable por la etiqueta del destino. Prueba restauración y reversión; un plan escrito no es evidencia de recuperación.
IA first y límites agenticos¶
La IA es un subsistema explícito y opcional; un proyecto sin IA es válido. Si se usa, declara modelo/proveedor y versión o límites de esa información, propósito, clases de datos de entrada y salida, retención/transferencia, fuentes de contexto y revisiones, procedencia de recuperación, conjunto/versión de evaluaciones, criterios de calidad y seguridad, alternativa de contingencia y condiciones de revisión humana. Mantén contenido no confiable de usuarios y recuperación separado de instrucciones. Prueba inyección de prompts, envenenamiento de recuperación, fuga de datos, afirmaciones sin sustento, rechazo y uso indebido de herramientas con casos adversariales representativos.
El plan generado por un agente o una llamada a herramienta es una solicitud, nunca una autorización. Una frontera determinista comprueba actor, capacidad, objetivo, alcance, presupuesto, TTL, riesgo y aprobación humana cuando aplique, inmediatamente antes del efecto. MCP, plugins y skills son capas de integración distintas; su presencia, cumplimiento de protocolo o ubicación en el repositorio no concede permisos. Evaluación, simulación, operación y aceptación humana son evidencias distintas ligadas a entradas/configuración/revisión exactas del modelo. Si cambia el modelo o la evidencia, las evaluaciones dependientes quedan obsoletas.
Registro y evidencia¶
La decisión arquitectónica conserva: contexto y objetivo; alternativas consideradas; dimensiones elegidas y extensiones; atributos priorizados y métricas; límites y amenazas; costos operativos; impacto regional/jurisdiccional pendiente; evidencia, propietario, fecha y condición de revisión. Un ADR registra una decisión material. Requisitos y artefactos se vinculan por IDs y versiones en el grafo SCAFFOLD; un cambio propaga revisión, no aprobación automática.
La comprobación automatizada puede validar vocabulario, campos requeridos, enlaces, reglas de dependencia y correspondencia declarada con diagramas/deploy. Pruebas de arquitectura, contratos, amenazas, recuperación, carga y evaluación de IA producen evidencia acotada a su revisión y entorno. Las excepciones se registran con razón, alcance, responsable y vencimiento. El perfil no prescribe proveedor cloud, framework, lenguaje, patrón, herramienta de diagramado ni cantidad de servicios.
Relación con ASILO, MILPA y SCAFFOLD¶
ASILO orienta fronteras de confianza, identidad, permisos, datos y efectos; MILPA conserva procedencia, clasificación, versiones y relaciones de artefactos; SCAFFOLD enlaza requisitos, decisiones, contratos, código, pruebas, diagramas y operación. El perfil de ingeniería aporta compromisos optativos y este documento una taxonomía de decisiones. Horcón puede validar estructura y declarar impactos; esa validación no demuestra la arquitectura real, cumplimiento normativo, seguridad o aceptación.
Perfil de ingeniería · Verificación de artefactos · Perfiles de aplicación