我的架构思想(三十一):架构是过程,而非结果——架构的表达与逻辑(理解线与线框)

阅读数:15 2019 年 10 月 12 日 17:05

我的架构思想(三十一):架构是过程,而非结果——架构的表达与逻辑(理解线与线框)

无论如何,在架构图中出现了一条线,通常都意味着它将一个整体划分成了两个部分。习惯性地,我们用纵向的线来表明领域的划分,而用横向的线来表明层次的划分,如图 25 所示。

图 25 整体划分成两部分

我的架构思想(三十一):架构是过程,而非结果——架构的表达与逻辑(理解线与线框)我的架构思想(三十一):架构是过程,而非结果——架构的表达与逻辑(理解线与线框)

由于不同部分自身“方框”的存在,因此这些横纵的线条也可能不被明确地划出。但就其含义上来说,它们都是存在的。例如,图 26 所示的“Spring 架构图”中隐含的一些领域与层次信息。

图 26 Spring 架构图

我的架构思想(三十一):架构是过程,而非结果——架构的表达与逻辑(理解线与线框)我的架构思想(三十一):架构是过程,而非结果——架构的表达与逻辑(理解线与线框)

无论是用线来隔开两个部分,还是用两个方框来表达这两个部分(进而由方框的边界来区隔它们),当我们表达出两个或多个部分时,每一个部分都需要一个明确的概念来指示。这涉及两个信息:其一,各个部分之间的分类依据;其二,各个部分所需的抽象指称。仍以上述“Spring 架构图”为例,图 27 中的“数据对象域”与“一般对象域”是二者的分类依据2,而 ORM 与 JEE 是二者各自的指称。由于 ORM/JEE 这样的指称一定程度上也暗示了分类依据,因此(在交流双方或团队具有相同的知识背景的情况下),也可以省略上述的线与分类依据标识。

2 它表明的其实是“普遍 / 特殊”这样的分类法。

图 27 Spring 架构图:ORM 与 JEE 之间的领域与分类依据

我的架构思想(三十一):架构是过程,而非结果——架构的表达与逻辑(理解线与线框)我的架构思想(三十一):架构是过程,而非结果——架构的表达与逻辑(理解线与线框)

在架构图中,横向的线也会有类似的表示法。例如,图 28 中 AOP 与 Core 是各自的指称。“核心”(Core)这一指称在一定程度上具有对其外围作“支撑”的语义,并且其注释中的 container 是容器框架的含义,这两个信息表达了它在对于其上的 AOP 等内容的支撑与包含关系。这些“暗含性的指称”使得在框架图上去除掉一些线(以及对其分类依据的标注)之后,仍然有较明确的含义3

3 领域与层次的分类依据是架构中非常重要的信息。一般有三种方法来表达它们,其一,通过线条和标注;其二,通过更为明确的分类指称;其三,在其他架构文档中加以详述。

图 28  Spring 架构图:AOP 与 Core 之间的层次与分类依据

我的架构思想(三十一):架构是过程,而非结果——架构的表达与逻辑(理解线与线框)我的架构思想(三十一):架构是过程,而非结果——架构的表达与逻辑(理解线与线框)

如上,我们得到了一个整体的各个部分:相互间可以用线条来区隔,其自身可以用方框来表示;并且,每一个部分都“应当(且必须)”有一个明确的概念,并有文字来指称它。

一个部分所包含的子域应当位于它的方框(当前域)之内。这些子域的概念应该派生自当前域,是当前域的概念的细分、子集、关联或延伸。有时为了图示的简洁,也可以将子域的指称直接置于当前域(的方框)之中。例如,图 29 中给出的两种图示具有相同的含义。左图中直接包含了一些子域的指称(列表),注意它只强调当前域对子域的包含关系,并不强调这些子域之间有何种分类依据或存在限制关系;而右图一定程度上会导致对子域之间是否存有层次性的误解。

图 29 Spring 架构图:JEE 的两种图示

我的架构思想(三十一):架构是过程,而非结果——架构的表达与逻辑(理解线与线框)我的架构思想(三十一):架构是过程,而非结果——架构的表达与逻辑(理解线与线框)

因此,如果不存在层次关系,应尽量避免右图的表达方法。

评论

发布