干系人、关注点与架构原则：先建立共同决策语言

统一订单项目讨论库存一致性时，后端团队希望库存平台成为唯一写入方，门店运营担心网络中断后无法销售，财务要求每次库存调整都能回到业务凭证，安全团队关注门店账号是否拥有过大的调整权限，项目负责人则担心改造范围超过十二个月预算。

这些意见不是“技术与业务沟通不畅”，而是不同干系人从不同关注点观察同一次变化。架构工作的起点不是让所有人接受同一张技术图，而是识别谁承担什么影响、关心什么结果、拥有什么决策权，再把共同约束沉淀为可执行的架构原则。

干系人不是通讯录

干系人是能够影响架构决策、承担变化影响或对结果负责的个人、角色或群体。仅列出姓名和部门没有意义，需要同时记录关注点、影响力、受到的影响和参与方式。

干系人	主要关注点	决策权或责任	需要看到的证据
全渠道业务负责人	增长、体验、上线节奏	能力优先级和业务结果	缺货取消率、渠道接入周期
门店运营	断网可用、操作复杂度、盘点责任	门店流程和例外处理	离线流程、培训成本、差异处理
交易与库存 Owner	规则一致、超卖、异常恢复	库存承诺和订单规则	状态机、对账、超卖率
财务与审计	账实一致、凭证、历史保留	财务口径和审计要求	调整凭证、状态轨迹、保存策略
数据负责人	语义、身份、质量和授权	数据定义与使用边界	数据责任矩阵、质量指标
平台与运维团队	容量、恢复、值班和成本	运行标准和事故响应	SLO、演练、容量与成本模型
安全与合规	最小权限、隐私和追责	安全控制与例外授权	权限模型、审计和风险评估

同一个角色可能同时是决策者和受影响者。例如门店运营既决定盘点流程，也承担系统切换带来的培训与营业风险。干系人分析需要描述这种关系，而不是简单分为“业务方”和“技术方”。

关注点要落到可决策的问题

“系统要稳定”不是有效关注点。可决策的关注点应该说明场景和后果：

• 门店网络中断 30 分钟时，是否允许继续销售，允许承诺多少库存。
• 支付成功但库存确认失败时，客户看到什么状态，由谁补偿。
• 商品身份合并错误时，历史订单和库存如何纠正。
• 大促峰值超出容量时，优先保护哪些客户和操作。
• 旧 POS 无法改造时，例外范围、对账和退出时间是什么。

这些问题能够进入架构要求、质量属性和迁移设计。抽象口号只能在会议上获得一致，无法指导实现。

用视角解决“同一张图看不懂”

架构视角（Viewpoint）规定为了回答某类关注点，应该选择哪些对象、关系和表达方式；架构视图（View）是针对具体系统和场景生成的实际表达。

关注点	合适的视角	不合适的表达
哪些能力优先投资	能力地图、价值流、能力热力	微服务部署图
核心事实由谁负责	数据责任矩阵、生命周期、数据流	只展示数据库 ER 图
系统边界如何协作	应用责任图、上下文关系、交互时序	只列技术组件
大促如何稳定运行	质量属性场景、容量模型、故障链路	业务流程图
旧系统如何退出	过渡架构、迁移波次、写入权威变化	只有目标架构图
管理层如何判断收益	结果树、路线图、收益指标	类图和接口清单

一张图不能同时服务所有干系人。视角的价值不是增加图表数量，而是防止架构师用自己熟悉的表达回答错误的问题。

架构原则不是价值观标语

架构原则是一条长期约束，它帮助不同项目在相似问题上作出一致决策。一条可执行原则通常包含：

组成	需要说明的内容
名称	稳定、容易引用的表达
陈述	必须遵守的核心规则
理由	它保护什么业务结果或风险
影响	对组织、数据、应用、技术和迁移有什么后果
度量	如何判断项目是否遵守
例外	谁能批准、需要什么补偿、何时退出

原则示例：一个事实只有一个权威修改方

陈述：在明确的业务范围和时间窗口内，同一核心事实只能有一个最终裁决方。其他应用可以保留读模型，但不能绕过权威方修改事实。

理由：避免会员等级、订单状态和库存锁定被多个系统独立修改，降低冲突、对账和审计风险。

影响：

• 数据架构必须定义事实语义、范围和 Owner。
• 应用架构必须声明写入权威和只读副本。
• 数据库权限和接口契约要限制非权威写入。
• 迁移阶段必须按渠道、区域或对象范围声明唯一写入方。
• 必须保留旧写入口清退和对账证据。

度量：核心表写入来源、跨服务直接写库、重复事实数量、无法解释的对账差异、旧入口新增流量。

原则一旦包含这些内容，就能进入方案评审、流水线和运行治理，而不只是文档中的一句话。

原则之间需要处理冲突

架构原则不是越多越好，也不会天然一致。例如：

• “核心事实统一”倾向集中修改责任。
• “门店断网可经营”要求在边缘保留局部能力。
• “数据实时共享”增加耦合和运行成本。
• “最小权限”可能降低紧急运营处理速度。
• “平台复用优先”可能延迟短期业务上线。

架构工作要明确优先级和适用范围。门店离线销售可以作为“唯一写入”的受控例外：离线期间由门店本地账本记录有限销售，恢复后按业务凭证同步并由库存平台裁决冲突。这样不是放弃原则，而是用范围、补偿和审计管理真实约束。

从关注点生成架构要求

关注点只有进入可验证要求，才能影响设计。以下链路展示门店断网问题如何落地：

干系人：门店运营
  -> 关注点：网络中断时不能完全停止营业
  -> 约束：门店可能离线 30 分钟，POS 无法实时访问库存平台
  -> 原则：核心事实统一 + 业务连续性优先
  -> 架构要求：离线销售使用有界本地额度，恢复后提交业务凭证
  -> 应用设计：POS 本地账本 + 幂等同步 + 冲突挂起
  -> 运行证据：离线交易量、同步延迟、冲突率、人工处理量

这条链可以解释为什么某个“看起来破坏集中式库存”的机制仍然符合整体架构，也能让治理团队判断它是否超出授权范围。

干系人沟通按决策节奏组织

所有干系人参加所有会议会降低效率。可以按决策类型组织参与：

决策	必须参与	主要输入	输出
架构愿景与范围	业务 Sponsor、能力 Owner、企业架构	驱动、结果、约束	范围、成功指标、授权
能力与价值流	业务 Owner、运营、产品、业务架构	客户旅程、流程和指标	能力地图、差距与责任
数据与应用责任	数据 Owner、领域团队、应用架构	语义、状态、系统现状	数据责任、应用边界
质量属性	业务 Owner、安全、平台、运维	峰值、损失、合规要求	SLO、容量、恢复、安全边界
迁移与例外	项目负责人、运营、架构、运维	依赖、窗口、风险	过渡架构、回退、例外

架构师的职责不是替所有人决策，而是让相关决策者在相同事实和约束下作出可追踪选择。

原则如何进入交付过程

原则如果只在 Phase A 被讨论一次，很快会失效。它应转化为不同阶段的检查点：

阶段	原则证据
方案	数据责任矩阵、应用“不负责”边界、候选方案取舍
开发	数据库权限、契约测试、依赖规则和审计字段
发布	写入来源、灰度范围、回退和数据对账
运行	业务指标、跨边界写入、例外存续和遗留流量
退出	旧入口、权限、任务、凭证和数据归档

这也是架构治理的连接点：原则负责提供稳定约束，治理负责检查约束是否仍然成立，并管理必要例外。

最小交付物

• 干系人及其影响、关注点、决策权和参与方式。
• 关键关注点对应的场景、约束和业务后果。
• 视角目录：每类关注点使用什么模型回答。
• 少而稳定的架构原则，包含理由、影响和度量。
• 原则冲突、优先级、适用范围和例外授权。
• 从关注点到要求、设计和运行证据的追踪链。

常见失效方式

• 把干系人登记成姓名和部门，没有关注点与决策权。
• 用同一张技术图向所有人沟通，导致每个人理解不同。
• 原则写成“高内聚低耦合”“安全优先”，无法检查。
• 原则数量过多且互相冲突，项目可以选择性引用。
• 例外靠口头同意，没有范围、补偿和到期日。
• 架构师代替业务 Owner 作价值与风险取舍。

能力验证

• 能从角色、影响和决策权识别真正的干系人。
• 能把抽象关注点改写成可决策的业务场景。
• 能选择合适视角回答能力、数据、应用、技术和迁移问题。
• 能写出包含理由、影响、度量和例外的架构原则。
• 能解释原则冲突时如何按范围和业务后果取舍。
• 能让原则进入设计、开发、发布、运行和退出证据。

总结

干系人分析和架构原则共同建立企业架构的决策语言。前者说明谁承担什么结果、关心什么风险，后者把跨项目重复出现的取舍沉淀成稳定约束。只有关注点能够追踪到要求、设计和运行证据，架构愿景才不是一次共识会议，而是后续工作持续使用的依据。