识别架构意图的三个入手角度：脉络、组织、关系

架构意图不是随口一说的主观偏好，它必须承接”经营角色对方向的设定”——若一个意图不体现方向，它顶多是局部的、边角的架构决策，够不上真正的架构意图。架构师的核心价值，就在于把这份”方向设定”翻译成”规模”（架构的边界/范围）与”细节”（架构部件之间的联接关系/联接件）。识别架构意图有三个具体的入手角度，都围绕”规模与细节”展开。第一，系统的脉络，体现方向性，包含内在动律（系统作为整体的核心运作规律——一般过程、限制条件、要素间的流转关系）和整体动向（系统的长期目标——是独立系统还是公开系统、是规模渐增还是功能渐增、是战略布局还是战术实现点）两个方面。第二，系统的组织，是对范围的考虑——决定哪些内容该放在一起，既定义组织的内含规模，也定义组织与外部的距离；这一点和系统脉络密不可分，是在一个整体性思考过程里反复权衡的结果。第三，组织间的关系，是对联接件的考虑——讨论各组织成员之间该如何通信、以什么形式通信、成本几何。作者用一个支付系统案例把三者串起来：脉络层面，一般过程是”用户A与用户B之间的一次资金转移”，限制条件决定了这个过程该实现成流水记录还是完整交易（取决于系统是否理解”支付场景”这个概念）、该不该引入token/ticket做身份识别（取决于是否理解”用户”这个概念）；组织层面，需要确定”支付场景、用户A、用户B、资金、资金转移”这五个构件是否都完整包含在系统内部，还是被划到外部；关系层面，需要确定用户A和用户B之间、以及他们与支付系统之间该用什么方式通信。三个角度反复权衡之后，最终收束成一句简洁的架构意图陈述：”一个跨领域的开放支付平台”。可迁移启发：写一份架构文档时，与其堆砌一堆零散的设计决策，不如先逼自己按”脉络（这个系统的核心运作规律和长期方向是什么）→组织（哪些东西该划进系统边界内）→关系（划进来的这些东西之间该怎么通信）”这个顺序梳理一遍，最终能不能收束成一句像”一个跨领域的开放支付平台”这样简洁、不含糊的话——收束不出这样一句话，往往说明架构意图本身还没有真正想清楚。

结构图：

flowchart TB
  A["识别架构意图的三个入手角度(围绕规模与细节)"]
  A --> F["系统的脉络(方向性)"]
  F --> F1["内在动律:一般过程/限制条件/流转关系"]
  F --> F2["整体动向:独立/公开,渐增类型,战略/战术定位"]
  A --> O["系统的组织(范围)<br/>哪些构件划进系统边界内"]
  A --> R["组织间的关系(联接件)<br/>通信形式与成本"]
  F -.->|"支付系统案例:用户A-用户B资金转移<br/>是否理解支付场景/用户/资金转移"| E1["最终收束:一个跨领域的开放支付平台"]
  O -.->|"支付场景/用户A/用户B/资金/资金转移是否都在边界内"| E1
  R -.->|"用户间通信/用户与系统通信方式"| E1