Question

现在，让我们再前进一步 4 ，将这一架构意图表达为一个概要的系统架构的模型 5 ，如图 19 所示。

图 19　一个概要的系统架构的模型

我们需要在后续的架构活动中补全它对于开发与部署的约束性，由此得出整个“架构团队”的完整工作集 6 。其中，功能层是不需要过深讨论的，因为它应当可以通过“通用办公系统架构 v0.0.0.2”逐渐细化而来，表现为一种 功能架构 （functional architecture）。

服务层可以用一种 静态的运行架构 （static view of process architecture） 7 来表达，例如将不同的功能包装并发布成服务，如图 20 所示。在图 20 中，角色定义服务是对功能层中的“角色集”的封装，而业务登记服务是对“功能集”的封装。“定义”与“登记”在一定程度上暗示 8 了两种封装的形式不同，前者可能是一个角色管理子系统，后者可能是一个调度框架中的注册模块。

图 20　服务层的模型

框架层是一种更高层级上的架构决策，它讨论驱动上述这些服务与功能的整体方式。亦即，框架决定了功能层运行在何种环境中，也决定了 服务层中的各服务 之间的结构关系，甚至也决定了整个功能、服务层的入口以及其后整个交互。当然，框架层的另一个有趣之处还在于它决定了用户——产品的使用者与系统打交道的方式，即接口。

框架是一种 动态的运行架构 （dynamic view of process architecture）。运行架构被框架层和服务层分为了动态与静态两个部分，这取决于你以何种视角来观察这些部件。例如，因为出现了“业务集”这一概念，所以所有业务可以视为静态的被组织单元，而其组织方式为“（业务）登记”；更进一步，框架为这些静态的业务而准备的机制可能就是“调度”或者“事务驱动”。这样的一个框架层，可能会表现为图 21 所示的架构。

图 21　框架层的模型

注意框架的“可运行特性”，这意味着框架必须能描述数据和（阶段性地）持有数据的逻辑之间的关系。上述架构中使用了箭头，用以指示某些信息流的流向（call）与转换（transation）。我们必须保证上述框架层在数据与逻辑关系上是完整的、足具的，否则框架本身便无法实现“动态的运行架构”这一目标。

产品层依赖 集成架构（integration architecture） 来表达——系统集成活动的输出通常是一个“产品”（product），并且其输入也依赖（其他的）产品。例如，系统运行依赖运行环境、数据库，以及具体由开发团队开发的代码包。我们的所谓集成活动，并非简单地将代码包 build 起来，而是指将代码包 build 成一个产品，并确保它与运行环境、数据库这些外部产品能配合起来工作。这个最终配合无间的整体，才是我们的 系统 ，也才是对用户而言有意义的 产品 。

对于上述系统，其最终的集成架构可以用图 22 所示的产品层的模型表达。

图 22　产品层的模型（面向产品的集成架构）

这个架构表达了维持框架层正确运行所需的环境、工具与测试脚本等部件。这些内容/部件中的一部分是开发活动所需产出的产品，一部分是第三方产品，并且一般来说后者是首选。大多数情况下，集成架构表达的是需要集成的产品内容及其之间的关系。此外，因为集成架构的内容是产品而非程序的调用接口，所以它们之间的关系将主要是组合、依赖与层次等，而非调用或数据返回。