2.2 子系统与软件架构

2.2  子系统与软件架构

了解子系统与软件架构的关系有两个方面的意义。

从解决问题的角度而言，了解子系统与软件架构的关系，有助于避免软件架构设计不足和高来高去的问题（可参考第8章）。软件架构要设计到什么程度？为了使软件架构能够为软件开发提供足够的指导和限制，软件架构师应当为复杂的子系统设计架构，而不是保持其黑盒子的状态止步不前。

从经验的运用角度而言，了解子系统与软件架构的关系，有助于充分利用架构设计技能。比如，有经验的软件架构师都知道，分层、MVC和管道过滤器等架构模式很少单独使用，而是结合使用或根据子系统的层次划分嵌套使用。如图2-5所示，就是一个分层架构模式和MVC架构模式结合使用的例子。

图2-5  分层架构和MVC架构结合使用的例子

作为软件架构师，必须思考“软件单元是如何组成粒度更大的整体的”这一问题。
在具体的架构实践中，一个软件系统往往首先分解为几个子系统，子系统又继续分解……如图2-6所示，它刻画了这样的软件分解场景：一个系统，由3个子系统组成；每个子系统，又由组成它的多个类来实现。子系统可以分配到开发组，每个类可以分配给具体的工程师实现。

图2-6  一个软件分解场景

更广泛而言，构成软件的单元具有不同的粒度等级。对于面向对象的软件开发而言，经常有这些软件单元：

 粒度最小的单元通常是“类”
 几个类紧密协作形成“模块”
 完成相对独立的功能的多个模块构成了“子系统”
 多个子系统相互配合才能满足一个完整应用的需求，从而构成了软件“系统”
 一个大型企业往往使用多套系统，多套系统通过互操作形成“集成系统”

类、模块、子系统、系统、集成系统，都是软件单元的具体形态，只不过粒度不同罢了。软件系统越复杂，不同粒度的分解层次就越多；比如，有的组织会引入“分系统”的概念，形成“系统－分系统－子系统－模块”的分级体系。

2.2.2  子系统也有架构

所谓系统，是指由多个元素组成的逻辑实体，它完成一组特定的目标或担负一定的职责。系统可以仅包含软件，也可以仅包含硬件，或者是两者都包含。

子系统是特殊的系统——只不过在特定的上下文中，这个系统作为更大的系统的一部分出现。
系统需要架构设计，而子系统如果足够复杂，则也需要架构设计。图2-7揭示了这一点：子系统作为特殊的系统，它也是由多个元素组成的整体，而架构规定了它是如何划分为多个部分的，以及规定了多个部分之间的交互机制和交互接口。

图2-7  子系统也有架构

2.2.3  子系统不同，架构不同

另外，不同类型的软件系统需要不同的软件架构设计，这似乎是很多人都理解的道理；但有时候，一个系统的不同子系统也应当有不同的软件架构。

举个例子。相信不少读者了解Martin Fowler所著的《企业应用架构模式》中介绍的事务脚本模式（Transaction Script）、领域模型模式（Domain Model）等“领域逻辑模式”。在实际的架构设计当中，这些模式的运用并不是“放之各子系统而皆准”的。例如，一个采用了分层架构的软件系统，它可能包含了报表、拓扑显示等子系统，这些子系统会有自己的内部架构吗？

图2-8所示的示意图给出了结论：拓扑子系统适宜采用领域模型架构模式，而报表子系统则应采用事务脚本架构模式。

图2-8  不同子系统采用不同软件架构的例子

对于此例，如果你熟悉网管软件，你可以想象这是个网络设备拓扑图的显示子系统；如果你熟悉UML建模，你可以想象这是个UML建模工具……拓扑子系统的业务逻辑复杂，诸如图元的排列、连接、移动、覆盖、复制和删除等问题涉及到不同的规则，应当充分利用对象模型的优势来解决这些问题。

至于此例中的报表子系统，其业务逻辑相对比较简单，通过SQL语句从数据库中提取数据非常方便，并且可以利用SQL语句进行一些统计和查找计算，因此宜于采用事务脚本模式（转而采用领域模型模式无疑是自找麻烦）；当然，报表子系统采用事务脚本模式对提高性能也大有好处。

2.2.4  不同实践者眼中的粒度

另外，在真实的软件实践中，还有一个问题不可忽略：粒度的相对性。也就是说，同一个软件单元，在不同场景下我们会以不同的粒度看待它。

我们举个具体的例子。这个例子看似极端，因为在大多数开发者看来，一个ActiveX控件是再小不过的一个单元了，但它对控件的开发方来说可能是个子系统。诚然，一个VB编程者可以把ActiveX控件拖过来就用，完全把它当成原子级的软件单元；而对于开发方，这个ActiveX控件（比如报表控件、音频编辑控件）就是一个蛮复杂的“子系统”，从需求分析到架构设计再到编码测试，所花费的时间一点儿也不比其他类型的软件项目少。
这就好比，对于除菌皂“研制人员”而言，肥皂和细菌都是复杂体：“研制人员”需要分析细菌的结构，设计肥皂的成分。另一方面，对于用除菌皂“洗手的人”而言，它们并不关心肥皂和细菌的内部。
由此看来，是复杂事物还是简单事物，要视对谁而言。在某个实践者眼中的最基本的组件，对另一个实践者而言有可能位于相当高的抽象层次上。对此，《Systems Architecting》一书的作者Rechtin就曾指出，“所有系统都有子系统，而所有系统都是更大系统的子系统”。此话再明确不过地揭示了一点：实践的不同场景使得软件组成单元具有递归性。

因此，我们应当立足实践对待软件单元的粒度问题（从第1章关于“软件架构是一系列有层次性的决策”的讲解中也可以理解本问题）：

 当进行高一级的架构设计时，子系统就是一个原子单元、一个黑盒；
 当进行子系统本身的设计时，它才变成一个结构复杂的白盒；
 第三方组件一般被看作原子单元，只需关心其对外接口即可——此时我们是使用它的服务；
 但当使用来自第三方的框架作为某一级系统或子系统的架构基础时，则应当仔细研究其结构——这是因为此时是使用它的结构而不仅仅是服务。

总之，懂得了“细节是相对而言的”这一点，软件架构师才能够游刃有余地根据情况忽略应该被忽略的细节，抓住设计大局。