我的架构思想(二十五):架构是过程,而非结果——系统架构与决策(参考模型 M0:细解各部分的形成过程与关系)

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

我的架构思想(二十五):架构是过程,而非结果——系统架构与决策(参考模型M0:细解各部分的形成过程与关系)

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

4 接下来两个小节,是对“架构形成模型 M0”的一个应用。我们假定了一个实例,并基于此实例展开了一个系统架构过程,注意它并非是一个已经被理论化的架构方法,因此许多名词借用了其他场景。

5 从现在开始,你可以想象成有一个“首席架构师”决策了这一系统架构模型,而我们后续要讨论的是其他架构的形成与表达。我们再晚一些会谈到“这一决策”事实上是与架构师自身的经验、背景有关的。

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

我的架构思想(二十五):架构是过程,而非结果——系统架构与决策(参考模型M0:细解各部分的形成过程与关系)

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

6 架构设计不单单依赖模型,也不单单“产出”模型图。架构过程在最终的架构文档中应当包括模型图、规格文档,还可能会包括关键子系统的形式化代码与流程图。在不同领域的架构中还包括特定的模型图(如数据架构或部署架构图),这一类的架构过程可能会将一部分设计工作也包括在内。对于我们在这里讨论的“架构”行为而言,仅仅是指架构师通过模型或抽象分析来得到系统的基本映像,并将它表达为一些图例以用于后续架构过程的指导与分析即可。

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

7 一般会把“process view”(参考 Philippe Kruchten 的“4+1 视图”)所对应的架构称为运行架构。这里采用了这一名词,但含义上有些不同。在本书的这一示例中,运行架构更确切地说是“系统运行环境的架构”,它表达了在系统架构的层面上对开发的限制与约束,因而包含了对服务和服务的运行框架的描述——这里的“服务”是一个与“结点”相对应的概念,而并非一个确切的(如 Java Runtime 中的.jar)包或组件。

8 在架构实作中是不应当存在所谓“暗示”的,架构师应当明确地将自己的意图表达出来。不过,“明确”的手段就未必是模型图了,因为架构师可以选择更为详实的架构文档来陈述这些意图。在这里,我们只粗略地讨论这种意图,并且为最终的(在本小节结束时将提出的)架构意图而设下伏笔。

图 20 服务层的模型

我的架构思想(二十五):架构是过程,而非结果——系统架构与决策(参考模型M0:细解各部分的形成过程与关系)

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

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

图 21 框架层的模型

我的架构思想(二十五):架构是过程,而非结果——系统架构与决策(参考模型M0:细解各部分的形成过程与关系)

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

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

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

图 22 产品层的模型(面向产品的集成架构)

我的架构思想(二十五):架构是过程,而非结果——系统架构与决策(参考模型M0:细解各部分的形成过程与关系)

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

评论

发布