Question

什么是系统的本质问题？这是我们要明确讨论的最后一个关键设问。就题设来说，“系统”的本质是领域集。这是一开始就讨论过并强加在我们这里的讨论之上的。但其本质上的问题是什么，却是一个还没有被讨论的话题。

若以现实系统为各个领域的目标，那么系统只需实现目标需求即可，亦即本质问题将是“能或不能实现”的问题。但是这将会得到一个“死的”系统：从系统被完成的第一时间开始它就不再增删任何东西；也没有任何对外的接口，因为它不面向新的领域。这样的系统并非不存在，事实上它大量存在着，并且是“高可靠系统”的主要开发方式。这样的系统的一个主要特点是它在架构上的确定性，与之对应而又匹配的，则是其领域集中的运作模式也相对确定。

但我们是在讨论复合领域集的问题。尤其其关键核心在于：由领域集构成的业务模式（犹如产业链等）是可能变化的，甚至是变化频繁的。一如本章最开始所讨论的，我们将“面向时间需求与空间需求”来进行架构，以应对这种持续变化。更进一步地，“变化”本身也只是需求，背后真正的问题——架构的本质问题，其实是对系统性的维护。

总的来说，可以将此前提及的种种思想归于在这一问题下的求解。例如，以架构形成的一般过程为参考，或架构以平台或框架为方向，或架构对战略的响应，等等，这些无一不是在讨论这样一个问题：架构需要提供何种程度的持续性，以使得它能够应对系统在构建和应用过程中的变化——并在这些变化之下保持“系统整体的一致”？

抛开上述这些具体方法，直面问题本身，那么 架构规划 也可能是另外的一种求解思路。仍以办公系统为例，从中长期来看，开发方推广该产品会存在一些明显的阶段。例如：

• 在早期可能应用方单一，所以系统功能明确，针对性强而定制性弱；
• 在一段时间之后，系统的应用方就多了，但缘于业务开展的情况，所以用户大多数都在类似行业当中，因此功能的定制性要求虽然强了，但其领域性仍比较单一，并且大体的使用流程和现场问题都类似；
• 再后，开发方可能要求该系统平台化——这基于两点要求，其一是业务推广开始面向通用领域，其二是功能的大量增加导致系统过于复杂；
• 最后，整个系统还可能走向跨平台的方向，例如面向不同的终端（如手机），以及加入不同的设施（如办公室签到设备），或者跨地域的办公等。

我们可以对这些阶段作出规划。首先，不同阶段的系统重点是不一样的，如表 3 所示。

表 3　架构规划在不同阶段中的重点

当我们将当前系统的目标与上述规划对应时，就很容易锁定我们“应有的”架构意图，并且能够通过阶段规划，来促使当前的架构意图契合业务方向对架构的要求。例如，就办公系统而言，我们可能将当前系统的目标设定为：

架构一期，快速实现的市场探针性产品。

基于这样的设定以及对其后的持续性的考虑，我们就有了进一步的架构决策。例如：

• 宜通过使用现有的成熟系统来搭建运行环境，加强现场团队的实施能力来解决客户的现实问题；强化现场团队的反应能力、反馈能力，对发现问题的敏锐度，以便更加准确地收集与响应客户需求。
• 宜通过敏捷开发团队的模式来实现产品功能，可以考虑让客户直接参与测试过程（例如试用或小范围测试），可以直接向客户提供 alpha 版本。可以考虑客户配合的现场调试环境。
• 简化产品化特性，例如说明书或安装包。

因此，在这个阶段的架构上，对集成性、重用性、移植性等的考虑就会非常少，类似集成架构、功能架构等的实施也可以很概略。

但是从架构的体系性上来考虑，即使在最初阶段的架构中，也不能缺少对后续架构阶段的设定。这至少包括两个方面：其一，后续架构阶段的启动条件；其二，后续架构过程“在当前架构中的”入手点。表 4 给出了一个示例。

表 4　架构意图在不同阶段中的变化与入手点

架构意图在各个阶段的不同变化，意味着我们可以用“有规划的变化”来讨论整体的架构意图。我们需要做的最后的一步工作是：将几个关键入手点连续起来，于是整个系统架构的脉络也就赫然可见了。

1. 更具体来说，后续的 5.2~5.4 小节讨论上述的设问(1)，而 5.5~5.7 小节分别讨论设问(2)~(4)。 ↩
2. 本书只讨论了决策过程模型，但并不否认团队推动架构的其他过程方法。 ↩
3. 一般意义的“功能架构”是“实现架构”中相当重要的组成部分，例如对客户需求项的映射，但这未能在图 18 中体现。 ↩
4. 接下来两个小节，是对“架构形成模型 M0”的一个应用。我们假定了一个实例，并基于此实例展开了一个系统架构过程，注意它并非是一个已经被理论化的架构方法，因此许多名词借用了其他场景。 ↩
5. 从现在开始，你可以想象成有一个“首席架构师”决策了这一系统架构模型，而我们后续要讨论的是其他架构的形成与表达。我们再晚一些会谈到“这一决策”事实上是与架构师自身的经验、背景有关的。 ↩
6. 架构设计不单单依赖模型，也不单单“产出”模型图。架构过程在最终的架构文档中应当包括模型图、规格文档，还可能会包括关键子系统的形式化代码与流程图。在不同领域的架构中还包括特定的模型图（如数据架构或部署架构图），这一类的架构过程可能会将一部分设计工作也包括在内。对于我们在这里讨论的“架构”行为而言，仅仅是指架构师通过模型或抽象分析来得到系统的基本映像，并将它表达为一些图例以用于后续架构过程的指导与分析即可。 ↩
7. 一般会把“process view”（参考 Philippe Kruchten 的“4+1 视图”）所对应的架构称为运行架构。这里采用了这一名词，但含义上有些不同。在本书的这一示例中，运行架构更确切地说是“系统运行环境的架构”，它表达了在系统架构的层面上对开发的限制与约束，因而包含了对服务和服务的运行框架的描述——这里的“服务”是一个与“结点”相对应的概念，而并非一个确切的（如 Java Runtime 中的.jar）包或组件。 ↩
8. 在架构实作中是不应当存在所谓“暗示”的，架构师应当明确地将自己的意图表达出来。不过，“明确”的手段就未必是模型图了，因为架构师可以选择更为详实的架构文档来陈述这些意图。在这里，我们只粗略地讨论这种意图，并且为最终的（在本小节结束时将提出的）架构意图而设下伏笔。 ↩
9. 因此，其一，基于对我们当前的、现实工作的过程回顾，是不可能找到“获得架构意图”的一般方法的；其二，我们在上一节中并没有再现某种实施过程，而是讨论了这一过程中的（可能的）思想脉络。 ↩
10. 换个简单而直白的说法，“架构是做出来的”这一观点就是这一架构方法的基本论调。 ↩
11. 注意，我们讨论的系统是“领域集”，因此这两个解对于“领域集所对应的行业、行业链”也是有效的。例如将语境置于：我们要构建这个行业生态链下的核心基础平台。——不过，事实上我并不知道我在说什么。 ↩
12. 架构为什么要分层以及如何理解架构的分层，是下一章讨论的内容。这里所谓的 三层架构 或 多层架构 这样的模型，是讨论中用以参考的、现实中的例子而已。 ↩
13. 既然我们在考虑“战略”问题，那么就必然有更多的角色会影响“办公系统”的架构过程。 ↩
14. 本例参考了《微计算机应用》2003.02 期，“基于工作流的 OA-ERP 集成”一文，作者郭应中等。 ↩