8.2 高来高去式架构设计的症状

所谓“高来高去式架构设计”，是指不能为开发人员提供足够的指导和限制的那种架构设计方案。高来高去式架构设计现象极为普遍，它可能带来的危害包括：

* 缺少来自架构的足够的指导和限制，开发人员在进入分头开发阶段之后会碰到很多问题，并且容易造成管理混乱，沟通和协作效率低；

* 对软件质量非常关键的全局性设计决定被拖延到分头开发期间草率决定，严重降低了软件产品质量；

* 没有完成化解重大技术风险的职责，可能造成整个项目失败；

* 团队成员对架构师意见很大，团队士气受到打击。

“发现问题是解决问题的一半”，下面为高来高去问题归类。

症状一：缺失重要架构视图。为了给团队的不同角色提供切实的指导，软件架构师应从不同视图进行架构的设计和归档。如果忽视了在某重要架构视图方面的设计，就会遗漏重要设计决策，具体的开发工作将会陷入缺乏应有指导和限制的困境。

症状二：浅尝辄止、不够深入。架构设计方案过于笼统，基本还停留在概念性架构的层面，没有提供明确的技术草图。于是，全局性的设计决策最后由具体开发人员从局部视角考虑并确定下来，造成技术和管理上的种种问题。

症状三：名不副实的分层架构。通过分层将架构系统模块之后，就迫不及待地喊出“分层架构”的口号，对各层之间交互接口和交互机制的设计严重不足。

8.2.1 缺失重要架构视图

如你所知，由于角色和分工不同,整个软件团队以及客户等涉及各自需要掌握的技术或技能存在很大差异。这就使得他们为了完成各自的工作，需要了解整套软件架构决策的不同子集。基于多重视图开展软件架构设计的方法，就能够解决上述问题。

实际经验表明，越是复杂的系统，越是需要从多个方面进行架构设计，这亲才能把问题研究和表达清楚。Grady Booch 在其著作《UML用户指南》中指出：“如果选择视图的工作没有做好，或者以牺牲其他视图为代价只注重一个视图，就会冒掩盖问题以及延误解决问题（这里的问题是指那些最终会导致失败的问题）的风险。”

为不同的软件系统进行架构设计时，对不同的架构视图的重视程度并不相同。例如，用于反映软件系统运行时的动态结构，以及组成软件系统的目标程序如何部署到硬件上的物理架构视图，对于分布式系统的架构设计来说是必不可少的。再例如，现在大量采用现成框架（比如众多开源框架）进行开发的软件系统越来越多了，这时开发架构视图就显得极为必要----开发架构关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架和类库，以及开发的系统将运行于其上的系统软件或中间件。

“缺失重要架构视图”的一种表现是，认为软件架构设计完全是用例驱动的，片面强调用例描述的功能需求。此时，架构设计对非功能需求关注不够，既没有深入设计软件的运行架构（对性能、可伸缩性、持续可用性等运行期质量属性很重要），也没有深入设计软件的开发架构（对可扩展性、可重用性、可测试性和可移植性等开发期质量属性很重要）。软件开发人员会感觉到架构设计方案离他们很“遥远”，既没有说明程序包的组织结构，也没有明确架构设计中的关键抽象和所采用框架的关系，等等。

8.2.2 浅尝辄止、不够深入

此时，架构设计方案往往过于笼统，基本还停留在概念性架构的层面，没有提供明确的技术蓝图。

概念性架构虽说不用，但“不用”不代表“够用”。概念性架构对开发人员的指导和限制是不够的。为了化解高技术风险，证明技术上的可行性，必须充分考虑技术，例如关键机制、核心技术和第三方框架都应明确。

另外，投票或售前演示级别的架构方案对市场活动或许早够了，但对实际的开发却显得过于笼统。比如，对如何达到高安全性目标，仅提出了采用传输加密、存储加密和数字签名等技术，但并未明确这些技术如何影响软件系统的其他部分，它们是否通过统一的服务接口封装，别的模块是直接调用它们还是利用AOP机制松耦合地触发等问题。同样，为了达到高可扩展性的要求，轻描淡写地“采用模块化设计”对实际开发也过于笼统。

无论上述的哪一种情况，它们造成的危害都是相同的；架构设计阶段遗漏了全局性的设计决策，到了大规模开发实际阶段，这些设计决策往往被具体开发人员从局部视角考虑并确定下来，如此一来，就会在模块协作方面出现问题，而且公共的服务模块也未能被识别出来。

8.2.3 名不副实的分层架构

“名不副实的分层架构”可以认为是“浅尝辄止、不够深入”式架构设计的一种具体表现，但由于分层架构的应用太广泛了，几乎无处不在，因此我们把它单独列出并着重讨论。

“名不副实的分层架构”是指那些号称采用分层架构，却仅用分层来进行职责划分，而没有规划层次之间的交互接口和交互机制的情况，而经典的分层架构属于“调用 - 返回”式的架构模式，和“主程序 - 子程序”架构模式同属一种类型。可以说，缺失交互接口和交互机制的分层架构中，其中“层”已退化成笼统意义上的“职责模块”了。

很多道理是相通的。一个公司，它的组织结构图就挂在墙上----再清晰不过了，但公司的运营却很混乱，这是为什么呢？来了任务、出了事情不清楚找哪个经理，此谓接口不清；日常的汇报体系如何，突发事件如何处理也未明确，此谓机制不明。事实，这何尝不是一种架构不够明确的表现呢？

对软件系统也是同样，而对缺失交互接口和交互机制的分层架构，许多开发人员依然得不到足够明确的指导。

“名不副实的分层架构”常见于各大报纸、各种市场材料。由于它们常冠以“总体架构”等名称出现，而不是实际上的“软件架构之冰山一角”，所以，有些没有经验的架构师会误认为他们要设计的也是这种“高来高去式的软件架构”。

让我们来重温一下学生时代的“反证法”：

（1）假设，市场材料里的软件架构不是高来高去的，而是程度足够深入的；

（2）那么，竞争对手可以轻松地从市场材料里获知你的核心技术；

（3）但是，是没有人会把核心技术写到市场材料里公开宣扬的；

（4）因此，假设不成立，这意味着市场材料里的软件架构是高来高去的。