8.3 如何克服高来高去症

批评应有理有度。

可以这么说，高来高去式的架构本身并没有错，它们往往属于概念性架构的范畴；一来它是对于市场宣传来讲已经足够了，二来它往往是循序渐进进行软件架构设计的良好起点。但是，如果停留在高来高去的架构设计上止步不前。并以之作为最终的架构设计方案，就会为后期开发埋下重大风险。

将高来高去架构设计的症结、问题与对策归纳如下：

-----------------------------------------------------

症结：缺失重要架构视图

问题：遗漏了对团队某些角色的指导

对策：针对遗漏的架构视图进行设计

-----------------------------------------------------

症结：浅尝辄止、不够深入

问题：将重大技术风险遗留到后续开发中

对策：设计决策须细化到和技术相关的层面

-----------------------------------------------------

症结：名不副实的分层架构

问题：只用了分层架构的分层概念来进行职责划分，没有明确层次间的交互接口和交互机制。

对策：步步深入，明确各层之间的交互接口和交互机制。

 8.4 网络管理系统案例：如何将架构设计落到实处

本节通过网络管理系统架构的“设计片断”，演示如何将架构落到实处的。

8.4.1 网管产品线的概念性架构

本案例的网络管理软件是作为软件产品线出现的，应充分考虑多个产品之间的重用，建立共享的产品线架构。

概念性架构清晰定义了架构的大局，并充分考虑了可移植性、可扩展性、性能和版权等商业因素，以及较长的生命周期等商业目标这些因素，制定了相应的高层设计决策。

但是，概念性架构毕竟是概念性架构，并不能为实际的开发工作提供足够的指导和限制。下面我们来进行实际架构层面的设计：篇幅有限，仅涉及识别功能块、规划功能块的接口、明确功能块之间的使用关系和使用机制等话题。

8.4.2 识别每一层中的功能模块

抽象的职责最终必须由具体的功能模块来承担。我们接下来必须识别每一层中的功能模块、以及各模块承担的职责。

8.4.3 明确各层之间的交互接口

在分层架构中，下层对于上层应尽量做到“黑盒”封装。这样一来，为每一层规划接口就显得非常重要。需要定义各层之间的交互接口。

8.4.4 明确各层之间的交互机制

更进一步，有了接口，就可以明确交互机制。设计中采用的其实是一种基于方法调用的事件机制。

8.4.5 案例小结

我们没有深入描述设计时所考虑的细节，而是着重描述了设计从不明确步步走向明确的过程。

我们还必须说明，如何将架构设计落到实处，其实根据架构设计视图的不同而不同。这是因为，不同的软件架构视图关注的对象不同（从模块--到程序包--到进程--到数据库表--到物理节点等），从而设计手段也就会有差异。