软件架构配置文件¶

状态：提议。 本配置文件扩展可选的技术无关工程配置。它不更改 ASILO、MILPA 或 SCAFFOLD 已接受的公理和要求，也不规定统一架构。应根据可验证要求和质量属性记录每个系统的选择；仅使用某种架构名称不能证明实现符合该架构。

声明相互独立的维度¶

应用形态、仓库结构、集成方式、运行拓扑和区域环境彼此相关，但属于不同决策。例如，系统可以是在单体仓库中的模块化单体，并作为容器部署在所选区域的 VPS 上。不得从一个维度推断另一个维度。

维度	示例值	需要记录的决策
应用形态	库/SDK、CLI、批处理/工作进程、API、Web、移动端、桌面端、嵌入式/边缘、多智能体系统	入口、使用方、边界和影响
结构风格	模块化单体、分层、端口与适配器、函数式核心、微服务、事件驱动、流水线、插件	模块、边界、依赖和组合方式；组合必须明确声明关系
仓库结构	单体仓库、多仓库、混合	所有权、包边界、测试、版本和协调变更
集成方式	同步请求/响应、事件、队列、流、文件/批次、本地调用	契约、交付、顺序、幂等性、重试和故障
运行方式	单进程、VM/VPS、容器、编排器、PaaS、托管函数、边缘、本地部署、混合或多云	部署单元、运维、可用性、恢复和所需可移植性
数据架构	关系/事务、文档、键值、图、分析、事件/流；无持久化	数据负责人、一致性、保留、迁移、恢复与证据
驻留	声明的提供方/区域、本地存储、复制、传输	分类、实际位置、备份、密钥及需由合格人员审查的司法辖区

关系型、文档、键值、图、分析和事件数据模型应根据查询、一致性、保留与运维需求选择；没有通用默认数据库。声明数据所有权、迁移、恢复和驻留并提供相关证据。不使用持久存储的项目应记录这一条件及理由。

这些术语是描述符，不是封闭目录。未知描述符应作为项目扩展保留并附说明；不得静默地将其等同于其他类型。

选择风格与拓扑¶

从能够满足可测试要求且保持变更边界清晰的最简单设计开始。模块化单体是一种选择，不是规则。只有在领域边界稳定、确有独立部署或扩缩需求、运维责任清晰，并具备处理分布式可观测性、网络、一致性、服务间安全和部分故障的能力时，才考虑微服务。不得仅因流行、团队数量多或仓库包很多而选择微服务。

当时间解耦、负载或集成需求足以证明采用事件驱动方式合理，且能够声明交付、重复、顺序、幂等性、保留和恢复时，才使用该方式。插件系统需要信任边界、带版本的契约、来源、兼容性、能力权限和加载策略；发现插件不代表授权或执行。分层和端口/适配器用于显式呈现依赖，不构成安全保证。

单体仓库与微服务是正交维度。一个单体仓库可包含多个可部署单元；多个仓库也可能生成一个单体。单体仓库需要模块所有权、可复现的选择性测试/构建、依赖规则和明确的接口版本。多仓库需要已发布契约、兼容性、协调变更和版本可追溯性。当碎片化成本超过已证明的收益时，应避免采用。

云、VPS 与运维¶

“云”描述服务/运维模式；“VPS”描述租用的虚拟机。二者均不能决定应用形态、安全性或司法辖区。VPS 需要声明补丁、加固、管理访问、防火墙、经测试的备份、监控、恢复、容量、证书和事件响应的负责人。托管服务需要声明提供方、所选区域、备份区域、相关子处理方、导出和退出流程。本地部署也应声明相应责任人。

每个部署应标出组件、网络和信任边界、数据流、存储、密钥、影响点、外部依赖、可观测性、降级、恢复和回滚。密钥不得写入制品；工作负载身份采用最小权限。上下文、容器和部署图必须对应可识别的源版本，并纳入影响图。

区域与司法辖区¶

软件区域化是可扩展的数据与运维配置：区域设置/格式、语言、时区、货币、单位、日历、地址和标识符格式，以及已声明的技术要求。它应能与国际核心和带版本的数据包组合。区域值是经过验证的配置/数据，不是从数据包加载的可执行代码。

提供方区域、界面区域设置、时区和适用司法辖区是不同变量，任何一个都不能自动决定其他变量。数据驻留、传输、法律义务、同意和保留需要有范围且现行的来源、明确的上下文和合格审查。发生冲突或证据缺失时，状态为未确定/需审查；没有授权时不得选择最宽松或最新的规则。

墨西哥专属要求应放入带版本的司法辖区数据包/配置文件，记录来源、权限、范围、审查日期、排除项、证据和负责人；不得放入国际核心。配置文件可以指出位置、保留、访问控制或导出等技术依赖，但不构成法律意见，也不决定法律适用性。架构应允许加入其他司法辖区数据包，而不复制或静默修改共享架构。

质量属性、威胁与运维准备¶

每个架构都要声明适用的质量属性、优先级、可测目标、测量方法、负责人和证据。选择相关项，例如延迟百分位与负载、可用性、RTO/RPO、无障碍、数据最小化、成本上限、可移植性或可维护性。没有工作负载、环境和测量窗口的数值只是目标，不是已验证性能。记录权衡和剩余风险。

安全从需求和威胁建模阶段开始，而非只在最终审查中考虑。识别资产、参与者、信任边界、数据流、滥用场景、依赖、密钥和影响点。遵循最小权限，并在相关边界检查身份、资源、操作和当前上下文；网络或仓库位置不产生信任。缺失或无效的必需控制应默认拒绝。架构和代码测试可检查已声明的边界，但不能证明不存在漏洞。

每项部署都要声明运维负责人，以及备份/恢复、事件响应、补丁、密钥轮换、监控、访问审查、容量和恢复等适用操作手册。必要时定义 SLO 与告警阈值。VPS、云、托管服务和本地部署由不同主体运维；不得根据目标标签推断责任人。应实际测试恢复和回滚，书面计划不等于恢复证据。

AI 优先与智能体边界¶

AI 是显式且可选的子系统；不使用 AI 的项目同样有效。使用时，应声明模型/提供方及版本（或信息限制）、用途、输入/输出数据分类、保留/传输上下文、上下文来源及版本、检索来源、评测集/版本、质量与安全标准、后备方案和人工审查条件。将不可信用户内容和检索材料与指令分开。用有代表性的对抗案例测试提示注入、检索投毒、数据泄露、无依据主张、拒绝处理和工具滥用。

智能体生成的计划或工具调用只是请求，不是授权。确定性的执行边界在产生影响之前检查参与者、能力、目标、范围、预算、TTL、风险和适用的人类批准。MCP、插件和技能是不同的集成层；它们的存在、协议合规或仓库位置都不授予权限。评测、模拟、运行和人工验收是不同的证据类型，并绑定到确切输入/配置/模型版本。模型或证据变化会使相关评测过期。

记录与证据¶

架构决策应保留背景和目标、备选方案、所选维度及扩展、优先质量属性与指标、边界和威胁、运维成本、未解决的区域/司法辖区影响、证据、负责人、日期和复审条件。重大决策记录在 ADR 中。通过 SCAFFOLD 图中的 ID 和版本关联需求与制品；变更触发复审，而非自动批准。

自动化可验证词汇、必填字段、链接、依赖规则以及声明的图/部署对应关系。架构、契约、威胁、恢复、负载和 AI 评估产生的证据仅适用于其对应版本和环境。例外应记录原因、范围、负责人和失效日期。本配置文件不规定云提供方、框架、语言、模式、绘图工具或服务数量。

与 ASILO、MILPA 和 SCAFFOLD 的关系¶

ASILO 指导信任边界、身份、权限、数据和影响；MILPA 保留来源、分类、版本和制品关系；SCAFFOLD 连接需求、决策、契约、代码、测试、图和运维。工程配置文件提供可选承诺，本文件提供决策分类。Horcón 可以验证结构并报告影响；这不能证明实际架构、法规合规、安全性或验收。

工程配置文件 · 制品验证 · 应用配置文件