我的架构思想(二十六):架构是过程,而非结果——系统架构与决策(“通过什么来影响什么”作为一般过程是可行的,但不完备)

阅读数:22 2019 年 10 月 12 日 16:58

我的架构思想(二十六):架构是过程,而非结果——系统架构与决策(“通过什么来影响什么”作为一般过程是可行的,但不完备)

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

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

我的架构思想(二十六):架构是过程,而非结果——系统架构与决策(“通过什么来影响什么”作为一般过程是可行的,但不完备)

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

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

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

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

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

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

9 因此,其一,基于对我们当前的、现实工作的过程回顾,是不可能找到“获得架构意图”的一般方法的;其二,我们在上一节中并没有再现某种实施过程,而是讨论了这一过程中的(可能的)思想脉络。

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

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

我的架构思想(二十六):架构是过程,而非结果——系统架构与决策(“通过什么来影响什么”作为一般过程是可行的,但不完备)

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

10 换个简单而直白的说法,“架构是做出来的”这一观点就是这一架构方法的基本论调。

评论

发布