1.5  PM Tool案例：领会软件架构概念

为了有助于领会软件架构的概念，我们引入一个名为“PM Tool”的案例。PM Tool是一个项目管理系统，提供项目计划、任务管理和资源管理等功能。本节希望结合案例来讨论软件架构，为读者理解软件架构的概念带来实感。

1.5.1  案例故事

PM Tool有一项名为“查看甘特图”的需求，用户要求“能够以甘特图方式查看任务的起始时间、结束时间、任务承担者等信息”。经过分析我们不难发现，PM Tool至少应提供两种查看任务计划的方式：一种是以表格的方式将任务名称、开始时间等信息列出，另一种是采用甘特图。如图1-6所示。

图1-6  PM Tool至少要提供两种查看任务计划的方式

任务是如何计划的？又具体分配给哪些项目成员？这些信息和PM Tool采用何种方式来展现应当是没有关系的。根据此分析，我们立即想到采用MVC架构，将业务逻辑和展现逻辑分开，如图1-7所示。

图1-7  和具体技术无关的架构方案

上面的架构设计，还处于“和具体技术无关”的层面。我们必须考虑更多的实际开发中要涉及到的技术问题，从而不断细化架构方案，这样才能为开发人员提供更多的指导和限制，也才能真正降低后续开发中的重大技术风险。
对于PM Tool要显示甘特图而言，“甘特图绘制包”是自行开发的，还是采用的第三方SDK，就是一个很重要的技术问题。考虑如下：

一方面，用户根本不关心“甘特图绘制包”的问题，他们只在乎自己的需求是否得到了满足；而项目工期是很紧的，自行开发“甘特图绘制包”势必增加其他工作的压力，为什么不采用第三方SDK呢？
另一方面，短期内决定采用的第三方“甘特图绘制包”可能并不是最优的，所以并不希望PM Tool“绑死”在特定“甘特图绘制包”上。

基于以上分析，架构师会决定：采用第三方SDK，但会自主定义“甘特图绘制接口”将SDK隔离。如图1-8所示。

图1-8  和技术相关的架构方案

有的读者应该已经看出来了，上述设计中采用了Adapter设计模式。

适配器（Adapter）模式
关键字：已存在/不可预见  复用
支持变化：由于Adapter提供了一层“间接”，使得我们可以复用一个接口不符合我们需求的已存在的类，也可以使一个类（Adaptee）在发生不可预见的变化时，仅仅影响Adapter而不影响Adapter的客户类。
结构：

图6-31  配置Linux下的DNS客户端