Question

通过产品、框架、服务与功能这样的层次，上述系统架构整体地表达了它作为“实现架构”对实现域和交付域（以及阶段）可能构成的影响。对照图 17（这里引用的是此前文字中的图例，所以图序号有异）所述的形成模型 M0，可以看到在该系统架构中：

图 17　一个可参考的架构形成模型 M0

• 功能架构：它是实现架构中的组成部分，把由能力架构映射而来的能力分割为基本独立的 功能 块，基本映射了用户的原始需求，并约束了开发架构中的功能模块。
• 运行架构（静态部分）：将这些功能包装并发布成 服务 ，用以约束开发架构中的包的组织与接口的设计。
• 运行架构（动态部分）：选择或实现可运行 框架 来驱动服务与功能，基本约束了开发架构中可选的第三方应用服务器，以及应当自主开发的、系统中的关键联接件，如事务服务框架等。
• 集成架构：以 产品 来封装和交付可运行框架，基本约束了部署架构可用的部件，以及部件之间的组合、依赖等关系。

综上所述，图 19 所示的系统架构可以通过 M0 模型展示的一般过程来完成决策，最终将在不同的阶段产出相应架构（一般称之为某种架构视图）来影响其他阶段的工作。在产生这些架构视图的过程中，隐含了大量的架构决策细节。例如：

• 功能架构中，账户子系统与部门子系统可以依赖 Windows 中的目录服务（直接使用或二次开发）；角色定义服务，意味着它需要依赖某种对定义（definition/ specification）的解析服务，也就是说，该服务应当基于某种策略服务器来实现。
• 运行架构的静态与动态部分，事实上是参考了 JavaBeans 模型。因此如果使用 J2EE 服务器，则应用服务器、Beans 容器及其运行框架，会话、事务等基础服务，以及在架构的各个层次上都有较为成型的解决方案。
• 集成架构主要表达产品的规划以及产品之间的组织关系，这与系统的“领域集”特性有关，也与系统规划（包括上述的框架选型）带来的可组织性有关。

由此可见，“架构形成模型 M0”的提出，提供了“通过什么来影响什么”的一般过程，进而对种种架构内容与阶段提供了参考。我们可以顺着这一过程来梳理架构活动，进而形成或明确我们在系统架构上的架构意图。如上一小节的示例中，已经渐行渐显地得到：

一个以企业管理应用为目的、以业务功能为核心的三层架构。

需要补充的是：我们在现实中的架构活动，通常是先“凭经验选择”了某种架构模式（如三层架构或多层架构），然后在此基础上进行框架和第三方产品的选型，最后再按照这些基础环境的约束来做自己的架构工作。——这一过程通常如此，但它只是一种可重复的实现方法，而无法解决“如何形成架构意图”这一问题 9 。

最后，我们对“架构形式模型 M0”作一些简化，就可以得到图 23 所示的系统架构的一般过程。

图 23　对“架构形成模型 M0”的简化：系统架构的一般过程

在上面的例子中，我们事实上是以 能力架构 为出发点来讨论实现，而缺少对体系架构的思考的。因此，我们提出了“如何定义实现架构，以使它满足系统的能力需求”这个设问，并基于“架构是在不同阶段形成的（即架构形成论）”这一假设，通过“一般过程”来探求系统架构的实施与决策 10 。