Question

那么，架构意图到底是什么呢？

架构意图需承架构的定义而来，它首先必是“经营角色对方向的设定”在系统上的体现。若架构意图不体现方向，则它将只是局部的、边角的一些架构决策 12 或意图 13 。架构师的核心价值，在于通过架构意图来将“ 方向设定 ”映射为“规模与细节”。其中，“规模”表现为架构的边界/范围，“细节”表现为架构部件的联接关系/联接件。

对于架构意图的识别，有三个入手的角度。这三个角度仍是“规模与细节”相关的，其一，是系统的脉络；其二，是系统的组织 14 ；其三，是系统组织间的关系。如果一个意图表现了架构师对系统上述三个方面的理解，则该意图应当视为架构意图 15 。

第一个方面，系统的脉络是对方向性的体现。这包括系统内在的动律与整体的动向两个方面。前者，即 内在动律 意味着架构师应当对系统（作为一个整体）的核心运作规律加以考察，这包括一般过程、限制条件以及最基本的系统要素间的流转关系。下面以支付系统为例。

• 一般过程：在某种支付场景下，用户 A 与用户 B 之间的一次资金转移。
• 限制条件：支付场景、用户 A、用户 B、资金以及资金的转移这五个因素是否被“当前系统”所理解。如果不理解支付场景，则应该将上述过程实现为流水，反之可以实现为一笔交易或基于订单的支付过程；如果不理解用户 A 或用户 B，则应该将上述过程置于一个会话或在过程中使用 token/ticket 以识别 16 ，反之支付过程应当自行决定是否需要对用户进行复核（例如站内消息或手机短信通知与验证）；如果当前系统不理解资金转移，则应当记录支付行为并提供外部查询接口，反之则可以完成资金转移。
• 流转关系 17 ：其一，用户 A 与用户 B 之间的消息通信（可选）；其二，系统与用户 A、用户 B 的消息通信，例如短信确认与通知等；其三，用户 A 与用户 B 的资金账户中的资金变化。

后者，即 整体动向 意味着架构师应当对系统的长期目标做出考量，这包括 18 ：系统是独立系统还是公开系统，是规模渐增还是功能渐增的系统，是战略上的布局还是战术上的一个实现点。以金融业务中的清算系统为例 19 ，它通常是一个独立系统，因而不需要公共接口；它会随业务量的增加而规模渐增，但不会在系统功能上有明显变化；它通常只是一个关键技术点，而不会影响到整个金融业务的战略构画。

第二个方面，系统的组织是对范围的考虑，它主要讨论将哪些内容放在一起的问题，它一方面决定组织在内含上的规模，另一方面也决定组织在外延间的距离。以上面的支付系统为例，系统中是否完整包括“支付场景、用户 A、用户 B、资金、资金的转移”这五个构件，是需要被确定的。正如上述——在第一个方面中的分析所体现的，系统的组织既决定了“限制条件”的细节，其本身也取决于对系统脉络的分析。亦或说，很难孤立地看待系统脉络与系统组织，它们是在一个完整的、整体性的思考过程中的反复权衡。这一权衡的基本依据是上述的 整体动向 ，例如若支付系统开放 20 ，则账户 A 和账户 B 必然要从支付过程中抽取出去，并且相关的流转关系必然依赖外部系统；若将支付过程理解为功能渐增的系统，则它必然不适宜开放，因为这意味着接口趋向于应付功能变化，进而导致接口变化——而接口频繁变化是不合理的；若它本身只是战术实现点，那么它的开放基础就将建立在技术方案（如数据架构或系统群集等）之上，难以对行业、渠道或领域构成实质性的影响。

第三个方面，组织的关系是对联接件的考虑，它主要讨论上述组织成员间的通信，并进一步决定通信的形式与其成本 21 。仍以上面的支付系统为例，我们假定 22 用户 A、用户 B 与支付场景都是外部系统，那么我们必须考虑的联接关系就包括：其一，用户 A 和用户 B 是否具有消息通信过程，如果有，应当如何实现，例如是实现为专用网络中的通信客户端，还是使用类似手机短信这样的第三方通信网络；其二，用户 A 和用户 B 与支付场景是否有关系，是否在支付场景中通信，例如站内短信、通知等；其三，这些外部系统与（当前）支付系统之间是否有通信关系，例如安装服务端通信模块，或依赖于在外部会话中建立凭据。

架构意图中最重要的是系统的脉络，其 整体动向 是本质性的需求，其 内在动律 是上述需求的表现与表达方式 23 。总体来说，任何一个架构意图的形成都是对三个“入手角度”整体的反复考量进而形成的一个最终认识，而决非其单一方面的阐述。例如，以上述的支付系统来说，最终的架构意图应叙述为 24 ：

一个跨领域的开放支付平台。

1. 做第一种回答的人，是关注到了不同视角下的差异，因此会把系统变得更为复杂的。做第二种回答的人（亦如后文中的讨论），则试图进一步从差异中找到共性，从而简化对系统的讨论。 ↩
2. 这并不一定决定我们的表达手法。的确存在这种可能：手法不同，但“表达的结果”中所呈现的意图却是相同的。 ↩
3. 某些组织关系中，并非是单一的“授权”问题，因此这种表达方式也并非万能的。 ↩
4. 此图用于反映思考与决策的 过程 ，阅读图解的基本方法是：当我们将“管理” 作为 “架构意图”，进而 决定了 “与现实系统的相似度”， 例如 ：与现实系统看起来类似。 ↩
5. 这并非不可取。许多生产系统就只需要“再造”现实系统的现场即可，但这也并不表明架构师不需要“意图”，因为再造的过程本身也是动态的，也可能是阶段性的（例如一期、二期这样的分期工程）等。 ↩
6. 仔细分析“规则化”本身，它可能是结构化的另一个代名词。在现实系统中的一部分行为可以被抽象为“逻辑的规则”，例如营销活动策略、折扣策略等等；另一部分则可以被抽象为上述行为“依赖的信息”，例如参与者信息、依赖资源的信息、事件信息等。这两类规则化行为与结构程序设计中的“数据+算法”有着抽象上的近似。 ↩
7. 它决定了逻辑“ if Auth.isManager(User1) then Auth.assign(User1, User2, 'aAuthDescription') ”的合理性。 ↩
8. 它决定了逻辑“ if Auth.has(User2, 'aAuthDescription') then doSomething(…) ”的合理性。 ↩
9. 严格地说，“管理”这一架构意图的由来是我们在小节“2.3 抽象概念与模型是展示架构意图的方式之一”中讨论过的——它来自于基于现实系统的 几点事实 的推论。但是存有两个问题：其一，这一推论过程是经验化的；其二，我们未讨论有关“架构意图的由来”的思考方法，而只是陈述了它的某一个实例（即“管理”）的由来。 ↩
10. “公案”，佛学禅宗用词，是对高僧言行的记录，可用作思考对象、座右铭，以启发思想，供人研究等。 ↩
11. 目前来说，“架构 v0.0.0.2”是一个不错的架构。尽管它离投入开发实施还很远，但就我的经验来说，它在“正确地架构一个系统”这一方向上有着相当可喜的表现。 ↩
12. 架构决策 是下一章要讨论的问题，但许多时候架构决策被混用为我们这里讨论的架构意图。 ↩
13. 这里的“意图”是指某些与架构无关的意图，或阶段目标的架构意图。 ↩
14. 组织在这里是有两层含义的：其一，它作为名词以表明 组成部件 ；其二，它作为动词以表明 部件之间的结构过程 。 ↩
15. 意图并不一定是“单纯”的。架构意图可能同时蕴含了架构师在其他方面（如公司政治、市场决策等）的考量，但我们这里只讨论其在外在表现上 能否作为 在系统架构与设计中一以贯之的架构意图，而忽视了其他方面。 ↩
16. token 与 ticket 是常用的系统外认证的技术。这意味着具有某个认证系统专门来验证用户 A 或用户 B 的真实性，并在系统间将一个或一组识别用的凭据 token/ticket 传递给当前系统与用户，以使当前系统能够可靠地识别用户。 ↩
17. 一个完整的支付行为涉及资金流与信息流，后者主要用于保障一个支付行为的可靠性。当考虑用户间的信息流转时，它可能是一个用户授信的支付系统；当考虑系统与用户的信息流转时，是在支付过程内加入了安全需求。 ↩
18. 这里只是列举了三个设问，它们事实上分别反映的是系统的三个方面的特征：依赖、复杂性与持续价值。 ↩
19. 这里讨论的是内部独立清算业务，跨行（银行间）与跨系统清算等业务与此有相当大的区别。 ↩
20. 这里的“开放”是指将支付系统作为一组可公开调用的服务，提供给第三方公司或其他领域中的业务过程使用。 ↩
21. 总体来说，我们是要削减通信成本的。因此，应尽量要求组织成员间无关系、不发生通信行为，或在发生通信行为时尽量不对当前系统的“一般过程”构成影响。例如，即使支付过程的确需要用户 A 和用户 B 发生一次通信来增强安全性，那么也应当尽量在支付场景中通信，而不是在资金转移中通信，亦即是将这一行为视为交易安全，而非资金安全。 ↩
22. 该假定是以“需要实现为开放系统”这一动向为基础的。 ↩
23. 也许不应该如此片面地定义整体动向与内在动律的关系。究竟是整体决定内在，亦或反之，是有哲学思考的意味以及观察角度的设定的。另外，质变与量变也是脉络中的一个关键思考，例如逻辑复杂性是否会决定架构意图？ ↩
24. 架构意图的叙述是简洁且毋庸置疑的。例如，此前的办公系统，在“架构 v0.0.0.2”中的架构意图就是：它是一个管理系统，而非业务系统。 ↩