通过产品、框架、服务与功能这样的层次，系统架构整体地表达了它对实现域和交付域(以及阶段)可能构成的影响。再来看一下图4-17。

□功能架构：将功能分割为基本独立的功能块，基本映射了用户的原始需求，并约束了开发架构中的功能模块。

□运行架构(静态部分):将这些功能包装并发布成服务，用以约束开发架构中的包的组织与接口的设计。

□运行架构(动态部分):选择或实现可运行框架来驱动服务与功能，基本约束了开发架构中可选的第三方应用服务器，以及应当自主开发的、系统中的关键联接件，如事务服务框架等。

□集成架构：以产品来封装和交付可运行框架，基本约束了部署架构可用的部件，以及部件之间的组合、依赖等关系。

综上所述，系统架构可以通过上述的一般过程来完成决策，最终将在不同的阶段产出相应架构(一般称之为某种架构视图)来影响其他阶段的工作。在产生这些架构视图的过程中，隐含了大量的架构决策细节。例如：口功能架构中，账户子系统与部门子系统可以依赖Windows中的目录服务(直接使用或二次开发);角色定义服务，意味着它需要依赖某种对定义(definition/specification)的解析服务，也就是说，该服务应当基于某种策略服务器来实现。yipindushu.com

□运行架构的静态与动态部分，事实上是参考了JavaBeans模型。因此如果使用J2EE服务器，则应用服务器、Beans容器及其运行框架，会话、事务等基础服务，以及在架构的各个层次上都有较为成型的解决方案。

□集成架构主要表达产品的规划以及产品之间的组织关系，这与系统的“领域集”特性有关，也与系统规划(包括上述的框架选型)带来的可组织性有关。

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

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

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

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

①因此，其一，基于对我们当前的、现实工作的过程回顾，是不可能找到“获得架构意图”的一般方法的；其二，我们在上一节中并没有再现某种实施过程，而是讨论了这一过程中的(可能的)思想脉络。②换个简单而直白的说法，“架构是做出来的”这一观点就是这一架构方法的基本论调。