【IT168 技术文章】

    决定软件系统质量的最重要因素是软件架构。一个好的架构要确保不同类型的关注点(concern)的分离，也就是说，当其中一个发生变化时不会影响到系统的其它部分。可以通过识别系统中的关键用例来构建架构。通过分析这些关键用例，可以构建一个弹性架构，也就是说，各种不同类型的关注点保持分离，而系统中的一部分发生变化时对其余部分的影响是最小的。同时，架构的设计也必须满足诸如性能、可靠性等系统级关注点。架构将在系统早期的一个关键的版本中得以展现，这是一个可执行的版本——即称为架构基线的版本。在建立架构基线之前可能需要花费几个迭代，但完成后，将证实你的假设以及系统开发的方法，因此也就能够有效地降低风险。基于该架构，其它部分的开发速度必将大大加快。

    什么是架构？ 

    架构无疑是非常重要的。什么是架构？如果你问五个不同的人，可能会得到五种不同的答案。架构，和许多其它词汇一样，是无法真实触及的东西，其感觉就像过程、用例、项目、组件一样。但是，这些术语可以通过描述的形式来使之具体化。我们可以理解过程描述、组件描述、用例规约、项目计划以及架构描述等。当谈及架构时，我们将讨论如何理解架构描述。因此架构是架构描述的语义，它包含了关于系统的主要决策，例如：系统元素是如何组织的？系统如何实现所需的功能？系统如何满足预期的性能、可靠性和其它质量特性？系统需要什么技术（例如，Web客户端、胖客户端，特定的消息中间件）？系统内部组织的结构是否能够弹性地响应功能、技术、平台等变化？是否有标准能够确保系统开发始终保持一致？例如，使用了什么设计模式？使用什么异常处理原则？

    根据项目的实际来考量系统的决策是很重要的。例如，你可能需要连接特定的遗留系统的接口，或者系统可能需要是可配置的、并且需要有定义系统参数的途径，或者系统还需要通过远程安装和管理，系统还可能需要处理特定业务领域的复杂性。这个列表还可以不断列下去。但架构不是系统的全部，它只是整个系统中最重要的20%的事情。

    什么是好的架构？

    什么是一个好的架构呢？无疑，一个好的架构必须满足诸如性能、可靠性等系统级的关注点。它必须是易于理解的，以便能够很容易地跟踪出架构中的哪一部分实现了哪些需求或用例。每一个类（稍后将组成包）都明确地扮演已定义的角色，履行该角色的全部的且仅仅是属于该角色的职责集。

    一个好的架构必须使每个关注点相互分离，也就是说系统中的一部分发生了改变，不会影响其它部分。即使需要改变，也能够清晰地识别出哪些部分需要改变。如果需要对架构进行扩展，影响也将会最小化，已经可以工作的各个部分仍将继续工作。使用面向方面技术来构建系统，可以有效地保持关注点的分离。

    分离功能需求。一般来说，我们希望保持功能需求之间是分离的，不管它们是以特性（feature）、用例或其它术语来表示。毕竟，它们都表明了不同的最终用户的关注点，并相互独立发展。你不希望某一个功能的变化会影响到其它的功能。功能需求通常是站在问题域的（例如，酒店管理、物流、银行、保险等）高度来表述的，很自然地，我们希望系统的特定功能从领域中分离出来。这样，易于把系统适配到类似的领域中。另外，一些功能需求会以其它功能需求的扩展形式定义，你也必须使它们相互独立。

    从功能需求中分离出非功能需求。非功能需求通常用来标识所期望的系统质量属性，安全、性能、可靠性等等。这将通过一些基础结构(infrastructure)机制来实现。例如，你需要一些授权、验证以及加密机制来实现安全性；需要缓存、负载均衡机制来满足性能需求等。通常，这些基础结构机制需要在许多类中添加一小部分行为（方法）。这就意味着基础结构机制实现的一点变动会对整个系统产生巨大的影响，因此要使功能需求和非功能需求之间保持分离。

   分离平台特性。现在的系统需要运行在多种技术之上。这些技术经常是与平台或厂商相关的。当一个厂商将技术升级到一个新的、更好的版本时，如果你的系统是紧密地依赖于该技术的前一个版本，那么要进行相应的升级并不容易。你当然不希望捆绑在某个特定的技术上。因此，你要使平台特性与系统保持独立。

    将测试从被测单元中分离出来。作为完成一项测试的一部分工作，你必须采用一些控制措施和工具（例如调试、跟踪、做日志等）。这些控制措施是为了使系统的运行流程符合测试要求的规程。工具是为了（在系统执行过程中）提取信息，来确认系统确实按照预期的测试规程执行。这些控制措施和工具，经常需要在测试过程中向系统内插入一些与系统一起运行的代码。这些措施和工具所插入的代码在测试完毕后就会被删去。因此，你会希望能将测试的实现从被测试的系统中分离出来。