架构参考（企业架构师 / 设计权威）
适用于受监管的欧盟/法国环境（银行业、医疗、国防）。法规细节会演变：任何标记为“验证”的内容在用于可交付物之前，必须对照当前官方文本进行检查。
参考文献索引
references/togaf-archimate.md— 在构建架构工作（ADM阶段、可交付物、治理、合规审查）或使用ArchiMate建模（层、元素、关系、视角）时阅读。完整路径${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/togaf-archimate.mdreferences/urbanisation.md— 在生成或使用法国信息系统地图（区域/街区/小岛、地图绘制）、指导计划、应用程序组合评估（TIME）或合理化/退役计划时阅读。完整路径${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/urbanisation.mdreferences/adr.md— 在编写或审核架构决策记录或决策矩阵（Nygard、MADR、Y-statement、加权标准、虚构示例）时阅读。完整路径${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/adr.md
相关可交付物模板：${CLAUDE_PLUGIN_ROOT}/skills/deliverables/templates/dat.md、interface-contract.md、flow-matrix.md。
法规细节（GDPR、DORA、NIS2、HDS、II 901、IGI 1300……）位于 sector-compliance 技能及其行业参考文献中（${CLAUDE_PLUGIN_ROOT}/skills/sector-compliance/references/）；本技能仅涵盖架构影响。
1. 角色：设计权威
拥有：架构原则和标准；目标架构和路线图；结构性决策（ADR）；跨领域和专家的协调一致性；附带到期日的豁免（dérogations）；架构合规性审查；架构层面的技术债务登记册。 不拥有：安全风险接受（业务风险负责人/认证机构，由RSSI提供建议）；个人数据决策（控制者，由DPO提供建议）；预算/进度安排仲裁（COPIL）；生产变更（CAB）。
审查关口
| 关口 | 时机 | 检查内容 |
|---|---|---|
| G0 范围界定 | 指导说明 | 与目标/路线图的契合度，识别出的选项，法规范围，数据的主权类别 |
| G1 设计 | DAT / 接口合同草案 | 原则合规性，量化的NFR，集成模式，数据所有权，安全架构，可逆性 |
| G2 预构建 | 设计冻结 | 已接受的ADR，已签署的豁免，完整的交互矩阵，运营/灾备设计 |
| G3 预上线 | 在决定上线/不上线之前 | 实施情况与DAT对比，产生的债务登记，已测试的灾备，更新的DORA登记册/依赖关系图 |
审查结果：合规 / 有保留的合规（带行动项+日期） / 豁免（风险所有者+到期日） / 不合规（阻塞性）。
2. 架构原则
格式（TOGAF风格）：名称 — 声明 — 理由 — 影响。保持10-15条，每条在审查中可测试。受监管集成环境的默认集合：
| 编号 | 原则 | 可测试的影响 |
|---|---|---|
| P1 | 内置业务连续性 | 每个关键功能都有通过设计满足并经过测试的既定RTO/RPO |
| P2 | 内置和默认的安全与隐私（GDPR第25条） | 设计前对数据进行分类（DICT）；最小权限原则；传输和静态加密 |
| P3 | 每个数据域单一事实来源 | 每个数据实体有一个主系统和一个指定的所有者；其他系统持有受控副本 |
| P4 | 通过受管接口实现松散耦合 | 不允许直接访问其他应用程序的数据库；所有交换通过契约化的API、消息或文件进行 |
| P5 | 重用优先于购买，购买优先于构建 | 除非ADR另有说明，否则使用现有的共享平台（MFT、API网关、IAM、调度） |
| P6 | 标准与开放格式 | 首选开放协议/格式；专有格式需附带可逆性计划 |
| P7 | 可逆性与退出 | 每个外部服务都有退出计划；数据能以文档化的格式导出 |
| P8 | 可运维性是要求 | 监控、日志、调度、重启和DEX随解决方案一同设计 |
| P9 | 可追溯性与可审计性 | 端到端关联ID；审计轨迹按法律要求保留 |
| P10 | 基于分类的数据驻留与主权 | 托管选择源自数据分类（见第6节） |
| P11 | 简化与合理化 | 仅当没有现有组件合适时才引入新组件；每次替换都规划退役 |
| P12 | 自动化交付链 | 基础设施和部署作为代码，环境可重现 |
3. 目标架构与过渡架构
- 基线架构（现状）、目标架构（未来期望状态，通常3-5年）、过渡架构（平台：稳定、可运行、交付价值的中间状态）、差距分析（添加、移除、更改的内容）、路线图（工作包、依赖关系、退役日期）。
- 每个过渡状态必须能独立运行（受支持、被监控、有灾备覆盖、有文档记录）——项目可以在那里停止。
- 共存桥接（临时同步、避免双写、防腐层）是一级组件：拥有者、成本、终止日期、债务条目。
- 没有终止日期的“临时”将变成永久：在G1阶段拒绝它。
- 当遗留系统庞大且文档记录不完善时，优先采用增量迁移（绞杀者模式：通过一个外观模式逐步将功能路由到新系统），而不是全面替换。
4. 集成架构（宏观层面）
详细设计属于集成专家；架构师设定模式与规则。
| 模式 | 适用场景 | 避免场景 | 注意事项 |
|---|---|---|---|
| 点对点 | 少数稳定的流程，战术性 | 消费者多，频繁变更 | 意大利面条式（n²链接），无集中监控 |
| 主从 / EAI / ESB | 多异构系统，转换，集中治理 | 主从成为瓶颈/业务逻辑的单体 | 将业务逻辑排除在总线之外 |
| 通过MFT的文件传输 | 批处理，高容量，合作伙伴交换，遗留系统（在银行/IBM i中非常常见） | 实时需求 | 完整性检查，命名，截止时间，重发，加密，抗抵赖 |
| API主导（系统/流程/体验层） | 可重用服务，数字渠道，合作伙伴API | 批量数据移动 | API管理，版本控制，配额，OAuth2/mTLS |
| 事件驱动（发布/订阅，事件流，CDC） | 解耦反应，实时传播，多消费者 | 跨系统需要强事务一致性 | 排序，幂等性，模式演化，重放，事件所有权 |
| 数据平台（DWH，数据湖，湖仓一体，数据网格） | 分析，监管报告，机器学习 | 运营性事务集成 | 血缘，质量，保留，敏感数据隔离 |
| MDM / 参考资料 | 共享主数据（客户、产品、组织、患者身份） | 数据有单一自然所有者 | 治理和管理工作是真正的成本 |
经验法则：仅当调用方真正需要实时答案时才使用同步调用；域之间默认采用异步；为每个流程设计故障处理（带退避的重试、死信、重放、幂等消费者）；使用发件箱模式而非双写；仅在有限范围内使用规范数据模型（企业级规范模型很少能存活）；对每个契约进行版本控制；端到端使用一个关联ID。
5. 非功能性需求
量化每一个NFR；“高可用性”不是一个需求。
| 类别 | 指标 / 问题 | 陷阱 |
|---|---|---|
| 可用性 | 一段时间内的百分比，服务时间，允许的计划停机 | 忽略依赖链路；测量基础设施而非服务 |
| 连续性 | 每个业务功能的RTO / RPO（DMIA / PDMA），MTPD | 使用异步复制却承诺RPO为0；忽略批处理重启 |
| 性能 | 吞吐量，p95/p99延迟，批处理窗口，峰值因子，增长 | 测试平均值而非峰值；忘记月末峰值 |
| 可扩展性 | 时间范围内的容量，弹性 | 成本非线性增长的许可模式 |
| 安全性 | DICT评级，IAM，加密，日志记录，隔离 | 安全性在事后附加到设计上 |
| 可运维性 | 监控、告警、日志、重启、调度、自动化 | DEX在上线后编写 |
| 可观测性 | 跟踪、指标、日志、关联、业务KPI | 跨中间件缺乏端到端视图 |
| 可逆性 | 退出计划，导出格式，退出时间和成本 | 仅靠合同，从未测试过 |
| 互操作性 | 标准（例如支付中的ISO 20022，医疗中的HL7 FHIR——验证行业要求） | 标准的本地方言 |
| 合规性/驻留 | 数据位置，保留期限，法律保留，审计 | 备份和日志存储在约定区域之外 |
| 可维护性 | 升级节奏，供应商支持日期 | 支持结束发生在项目中期 |
| 可持续性 | 资源效率（法国的RGESN生态设计指南——验证状态） | 过大的非生产环境 |
可用性速查表（每年）：99% ≈ 3.65天；99.5% ≈ 1.83天；99.9% ≈ 8.76小时；99.95% ≈ 4.38小时；99.99% ≈ 52.6分钟；99.999% ≈ 5.3分钟。串联链路：A = A1 × A2 × …；冗余对：A = 1 - (1 - A1)(1 - A2)（假设独立故障——很少完全成立）。 RPO/RTO一致性：RPO受复制模式和备份频率限制；RTO包括检测、决策、故障转移、数据修复、批处理追赶和合作伙伴重新同步——不仅是技术切换时间。
6. 云策略与主权
先分类，再托管：数据类别驱动托管选项。
| 数据/系统类别 | 典型托管选项（需对照当前规则验证） |
|---|---|
| 公开/内部，非敏感 | 采用标准控制的公有云可接受 |
| 个人数据（GDPR） | 优先选择欧盟托管；向EEA外传输需要第V章依据和传输影响评估 |
| 健康个人数据（法国） | 需要HDS认证的托管提供商（《公共卫生法典》第L.1111-8条）；最近的HDS标准增加了EEA内的数据位置要求——验证当前版本和过渡日期 |
| 国家服务、国家运营商及列名的GIP的“特殊敏感性数据” | 通过SecNumCloud认证的产品，或ANSSI认可为等效的欧盟/EEA认证：SREN法律第31条（2024年），2026年4月14日第2026-272号法令，2026年8月12日命令；2021年（2023年更新）的“云中心”原则将预期扩展到其他国家信息系统——这些文本中存在豁免制度 |
| 传播限制（DR） | 经过II 901认证的系统；特定的托管限制——需验证 |
| 保密（秘密/绝密，IGI 1300） | 专用认证基础设施；通常排除公有云 |
| 银行关键或重要功能 | 允许，但需满足DORA第三方要求、外包规则（EBA指南）以及需要时的监管机构通知——需验证 |
SecNumCloud：ANSSI根据v3.2版要求基线（2022年3月8日；2026年8月12日命令批准的版本）对云服务提供商进行的认证。除了技术安全要求外，其第19.6节还提供了针对非欧盟域外法的保护：提供商在欧盟设立，非欧盟股东个人持股不得超过24%，集体持股不得超过39%，数据存储以及服务的管理和监督均在欧盟境内进行。“主权”营销标签不是认证：要求查看认证证书及其确切的服务范围。 域外暴露：根据数据类别评估非欧盟法律访问风险（例如，美国CLOUD法案，FISA第702节）；使用客户持有密钥（HSM/BYOK/HYOK）进行加密可降低但不能总是消除风险。 可逆性条款（合同 + 架构）：退出计划和协助期；以文档化的开放格式导出数据和元数据，成本不可过高；删除证书；文档和配置导出；退出期间的服务连续性；通知期；子处理者列表；审计权。欧盟数据法案（(EU) 2023/2854号法规，第六章）自2025年9月12日起适用：提供商必须支持切换，并且截至2027年1月12日仅可收取其实际切换/出口成本，之后不得收取任何费用。 架构赋能：可移植工作负载（容器、IaC），标准数据库或有文档记录的迁移路径，避免核心功能深度耦合专有PaaS，除非ADR接受，定期退出测试（至少导出并在其他环境恢复）。 云迁移选项（6R/7R）：淘汰、保留、重新托管、搬迁、重新平台化、重构、重新购买——根据组合评估（见信息化规划参考）为每个应用程序做出决定。
7. 技术债务管理
- 类型：架构（错误模式、耦合度）、过时（受支持版本终止）、代码、数据（质量、重复）、运营（人工步骤）、文档、安全（延迟修复）。
- 登记册：项目、类型、位置、原因（通过ADR有意为之 / 偶然发生）、利息（每期成本或风险）、本金（修复成本）、负责人、截止日期、关联的ADR/豁免。
- 过时日历：操作系统、数据库、中间件、运行时、ERP版本、IBM i版本的供应商支持结束日期；标记任何在24个月内结束支持的内容。
- 资金：预留明确容量（通常引用交付容量的15-20%——具体取决于组织）；项目免除产生的债务计入该项目成本。
- 影响关键功能的债务是ICT风险：在风险框架中报告，而不仅仅是IT积压事项。
8. 从架构视角的DORA ICT风险
(EU) 2022/2554号法规，自2025年1月17日起适用，由RTS/ITS补充。以下条款编号为指示性的：在可交付物中引用之前，请根据EUR-Lex确认。
| DORA主题 | 架构贡献 |
|---|---|
| ICT风险管理框架（第6条） | 架构原则、标准和目标架构作为文档化的控制措施 |
| 识别（第8条） | ICT资产和信息资产清单；业务流程与ICT服务的映射；依赖关系图 |
| 保护与预防（第9条） | 安全架构（网络分段、IAM、加密、API安全）；设计时纳入ICT连续性 |
| 检测（第10条） | 可观测性、监控、日志记录、端到端可追溯性 |
| 响应与恢复（第11条） | RTO/RPO、灾备设计、恢复程序文档化、定期灾备测试（由架构指定能力，由运营团队执行） |
| 备份管理（第12条） | 备份策略与频率必须满足DORA要求的RPO：对关键功能，RPO不得超过关键操作数据允许的合理时间（审计员期望分钟级/小时级，而非天级）；备份隔离（不可变，基础设施或逻辑隔离，不可从生产网络删除） |
| ICT项目变更管理（第20条） | ADR流程、设计审查关口（G0-G3）、合规性裁决、技术债务登记册 |
| 与ICT第三方风险相关的合同条款（第28-30条） | 可逆性条款、数据出口计划、审计权、子处理者透明度 |
| 数字操作韧性测试（第24-27条） | 架构中内置可测试性——对关键功能，必须支持TLPT（威胁主导渗透测试） |
| 报告（第19条） | 架构报告（架构状态、债务、豁免、对韧性指标的控制状况） |
| ICT风险集中化 | 避免单一供应商锁定的架构（每项DORA关键功能有多个独立供应商或备用方案）；架构中应识别并缓解供应商和地理风险集中 |
架构师检查清单：每个新系统或主要变更是否登记在ICT资产清单中？其业务影响和恢复要求是否已量化？是否已评估依赖关系的韧性？其数据是否根据DICT/GDPR/DORA关键性分类？
9. 跨专家一致性检查清单
在每个G1/G2审查中，检查这些一致性点。在执行摘要中明确回答。
| 维度 | 问题 | 来源 / 联系人 |
|---|---|---|
| 业务 | 架构是否满足可度量的业务收益？过渡状态是否交付价值？ | 产品经理 / 项目发起人 |
| 数据 | 是否识别并建立了每个数据域的真实来源？数据分类是否驱动流程设计？ | 数据负责人 / 首席数据官 |
| 安全 | 架构是否通过设计满足DICT要求？数据流是否经过审查以防止侧信道泄漏？ | 安全架构师 / RSSI |
| 运营 | 解决方案在达到稳定状态后是否可由值班团队支持？DEX是否包含部署、重启、监控、恢复？ | 运营负责人 / 值班经理 |
| 集成 | 是否识别了依赖关系？交互是否针对失败和重放进行了设计（幂等性、死信）？ | 集成专家 / 中间件负责人 |
| 应用 | 组件边界、语言和框架是否符合标准？是否存在已知的版本过时问题？ | 应用架构师 / 首席开发人员 |
| 基础设施 | 是否检查了资源、增长模型、许可证、备份容量以及基础架构即代码的状态？ | 基础设施架构师 / 云平台团队 |
| 法律/合规 | 合同是否包含可逆性条款和数据出口？监管机构的通知要求是否已安排？ | 法律 / DPO / 合规官 |
| 项目管理 | 工作包、预算和风险档案是否反映架构选择（过渡的运营成本、债务利息、退出成本）？ | 项目经理 / COPIL |
输出到可交付物中：针对每个维度的“检查 / 未检查 / 不适用”状态，以及映射到相关性、行动项或ADR的任何关注点。