红叶

  软件设计是一种把软件需求转换为软件实现的手段或活动。架构是软件的一种高层设计，一种软件结构，同时架构也是为了反映如何满足一系列相互有冲突的需求的一个权衡。比如说，某些客户会要求系统满足高性能，而另一些客户会更加关注系统的高扩展性，高性能和高扩展性在某些方面就存在一定的冲突，我们作为架构师（设计者）需要在这种冲突中寻找一个平衡点，并在我们的具体架构中体现这个平衡。极端的满足任何一种需求都是很危险的，都不可能达到客户的满意度。架构师（或设计师）的一个很重要的任务就是寻找这种平衡点，并对每个平衡点应用一种解决方案（这种解决方案可能会是某一种设计模式），这些解决方案的集合就构成了架构师对这个系统架构的决策。

  什么样的软件架构决策是好的？我们如何得到这种好的架构决策呢？这两个问题提到了软件架构的两个重要方面：第一个问题涉及对软件架构的分析和评估，第二个问题涉及软件架构的设计过程。下面分别简单讲述软件架构的这两方面主题。

  第一个问题：我们如何来评价软件架构决策的好坏？首先，大家要先弄清楚软件架构的目的和意义。我们开发软件是为了解决客户对软件的需求，而客户对软件的需求包括有功能性需求、质量需求以及一些约束条件。而这些需求可能存在一些相互冲突的方面，如何确保这些需求“和谐相处”，以及对这些需求寻求一个合理的平衡关系，这就是判断一个架构的决策是否“好”或“坏”的关键依据。因此并不是极端满足需求某方面的软件架构的决策（比如高度可扩展的架构模式）就是好的决策，反而好的软件架构决策往往兼顾了软件的所有需求的一个加权平衡（每个需求可能有不同权重）。简单的来说，一个好的软件架构的决策，是合理满足了项目所有干系人对软件需求的加权平衡的决策。目前，软件架构理论的发展，使我们已经有了一些分析和评估软件架构的手段，如架构的权衡分析法（ATAM）、成本效益分析法（CBAM）。对架构的分析评估方法的讨论可能需要另外一篇文章的内容来讲述，这里就不作深入展开了。

  第二个问题：如何获取一个好的软件架构的决策？上两节讲述了什么是软件架构的决策，以及什么是好的架构决策，在这些概念的基础上，我们来认识一下获取好的软件架构决策的过程，这其实也是软件架构设计的一个过程。软件架构的设计过程简单描述如下：

  1. 确定影响架构的关键因素（称之架构驱动因素）：关键的用例（功能需求）和质量需求，以及一些关键约束。并确定这些因素的优先级。

  2. 选择要分解的模块或系统（第一次一般是整个系统）。选择上述架构驱动因素，对应于该模块或子系统，根据这些架构驱动因素选择或构造满足驱动因素的架构模式（架构决策），然后对模块或系统进行分解成子模块或子系统。

  3. 实例化模块，并根据用例（功能需求）分配功能。

  4. 定义子模块或子系统的接口。

  5. 验证用例和质量需求，并对用例和质量需求进行求精分解，使之作用于子模块或子系统。

  6. 对需要进一步分解的子系统或子模块重复上述步骤。

  在模块分解的过程中，我们对目标系统进行了不同层次抽象，分离了系统的关注点——把系统易变、复杂的部分进行分离，解除不必要的偶合，使系统逐步满足影响架构的关键因素。我们通常会把一个目标系统分解成一个个的子系统、组件或服务，也会把这些子系统（组件、服务）进行归类到不同的层次，也会给这些子系统（组件、服务）定义提供者接口和需求接口，并且也会考虑以一种机制组织这些子系统（组件、服务），比如采用“微内核模式”、“MVC模式”、“依赖注入模式”、“插件集成模式”、“持久化机制”、“消息通信机制”、“远程调用机制”等等。这些都是通过架构模式或架构决策来体现的。

  但是，我们为什么要这样做？或者说我们为什么要采用这样的软件架构决策或这样的软件架构模式？这就是为了满足软件需求的一个平衡：在降低耦合、增强内聚、提高重用性、高扩展性、高性能以及经济性等方面的一系列平衡。然而要达到这些目标是困难的，是受很多因素制约的。我们架构能做到多少耦合降低才够？做到多少可重用才够？做到多少扩展性才够？在目前的项目时间内能做到吗？投入的资源能力能做到吗？等等。这些问题如果不能解决，我们做架构设计就是盲目的。这些问题又不是互相独立的问题，它们之间有着互相依赖、互相制约的关系。合理解决这些问题之间的关系，或者是找到这些问题的一个平衡点或一些列平衡点，我们才可能确定一套合理的解决方案，也即我们所说的软件架构的决策。上述的软件架构设计过程也就是我们寻找解决需求平衡的一个架构决策的方法。

  所以说，同一个问题如果只考虑功能需求，那么任何一种能满足这些功能需求的解决方案看上去似乎都不错，但往往这样做的结果用户并不满意。只有对这些包括质量需求、功能需求和约束条件都做出一些合理的权衡，并针对这些权衡给出一个合适的架构决策，实现满足这个决策的系统，这样的方案才是最合适的解决方案，也才能让客户真正满意的解决方案，这就是软件架构所要达到的目标，架构决策的意义也在于此。