Question

基于一般过程的设问，无助于讨论系统架构的整体实施走向，即“将向何处去”的问题。关于向何处去的问题，我认为若架构本身是应对规模问题，是面向领域集的，那么系统架构的演化方向必然只有两种：要么更大，要么更小。我常常将这两个方向称为“大到看不见”与“小到看不见”。

一个架构总是对它的构成部件在边界与联接件两个方面的设定。所谓设定，即是明确边界的范围，或明确联接的方法。然而，架构的主体——系统本身，却是动态地基于现实系统而演进的。如果我们有一个极端明确的边界约束，例如“由 A、B、C 三个部分构成”，那么当系统需要加一个新的领域时，架构就失效了；如果有一个极端明确的联接方法，例如“必须让 A 成为 B、C 的中间环节”，则系统中将不可能容纳未知的 D，因为 A 不能预知 D 与 B、C 的关系。

我们似乎是在讨论“无穷边界与关系”的系统，但系统架构对应用与子系统（以及其相应业务）的“可容纳性”决定了这必然是系统架构的方向。因此，就“系统架构”这个领域出现的本质来看，它就应当具有两点特性：

• 它能反映系统长期演化中的不变性，以在演化过程中持续用于对系统的讨论；
• 它不能是系统阶段实现的负担。

显然，系统架构的作用与其方向上构成了一对矛盾。但是在我们的实践中，这个矛盾是有解的，亦即所谓平台（platform）与框架（framework）。

这两个解，也是对系统架构中的“体系架构”的两个抽象 11 。首先，架构的支撑性应当以数据为核心，也就是说，平台通常是围绕数据的位置、功用、生存周期或其分布特性来规划的，例如常提到的三层结构在本质上就有平台化的倾向，因为它明确了交互数据、应用数据与系统数据在三个层次上的位置，以及相互间的产生、转化过程。其次，架构的调度性应当以逻辑为核心，也就是说，框架应当追寻架构对象——系统——的一般过程，并将它实现为架构的核心调度逻辑，例如 COM 框架，其核心就是组件的 register-request 这个过程。

若系统架构以平台为方向，则应当力求“大到看不见”；若系统架构以框架为方向，则应当力求“小到看不见”。所谓“看不见”，就是指该架构的存在不应当对系统的其他部件（例如对应于不同的领域的子系统）的实现构成影响。我们做架构的目的并不是要做出一个东西来阻碍我们的开发实施工作。我们的现实目标是“做一个系统”，而“系统的架构”是用来讨论系统的一个工具；如果这个工具最终影响了系统的形成，影响了系统本身，那这个工具便失去了原初的价值。

无论是做平台，还是做框架，最终的目标都是让系统基于它或使用它，而又无视它。