这一章，从技术的层面来说明软件架构很重要的十三个原因:

• 使系统拥有某些质量属性

  • 一个系统是否有它需要的属性完全由它的架构决定，下面有一些场景
    • 如果系统需要很高的性能，就需要考虑元素的那些基于时间的行为
    • 如果可修改性是重要的，就需要保证对系统的变更只会影响到小部分的元素
    • 如果系统需要是高度安全的，就需要对内部元素进行管理，保证元素只能接触到它被允许接触的信息
    • 如果系统需要很高的可扩展性，就需要避免对硬件资源的硬编码，使得如果换用好性能的硬件设备不会对系统产生过多的影响
    • 如果项目需要先产生有关系统的可以迭代增加的系统子集，就需要考虑组件间的关系
    • 如果希望系统中的元素被其它系统重用，就需要把元素间的耦合降到最低，这样，当从系统中抽取某个元素的时候，不会附带着一系列的元素。
  • 虽然架构对系统很重要，但是只考虑架构并不能保证系统的质量属性和功能，只有对设计，架构，编码，实现等一系列过程的很好的把握才可以达到期望值

• 解释和管理变更

  • 在实际的软件开发过程中，变更是在整个开发周期中都会存在的
  • 开发人员其实不会从头开始，重新创建，相反他们在现成的架构的约束和代码块下进行开发，使其适应新的特征和新的环境
  • 每一个架构都把可能的变更分为三类
    • 局部变更：只需要修改某个单一的元素，比如对价格逻辑模块增加一条新的业务规则
    • 非局部变更：需要对多个元素进行修改，但是底层架构不变。比如对价格逻辑模块增加一条新的业务规则，并在数据库中增加这个新的业务模型需要的字段，然后对用户界面进行修改，把新的规则显示在用户界面上
    • 架构的变更：可能就是对整个系统的变更，比如把CS架构变成BS架构
  • 显然，我们最希望系统产生的是局部变更，这样的修改会相对容易
  • 合理的分析架构可以使我们对系统处理变更的能力进行预测

• 预测系统的质量属性

  • 软件架构不但能使系统拥有某些质量属性，还能对系统的质量属性进行预测
  • 实际上，软件架构是可以在系统开发和集成之前根据该架构的评估进行合理的质量预测，这样就可以以得到特定的某些属性为目的做出决定，如果发现执行了某些决定，就知道和这些决定相关联的可以产生的属性是什么
  • 预测有助于很早的发现架构设计中存在的问题，并解决它，而不是等到后面的开发过程中再解决方案，这样就相对比较麻烦了

• 增强干系人之间的联系

  • 软件架构通常是对整个系统的一个抽象，大体上通俗易懂，所以可以让那些不具备专业知识的干系人对系统也有很好的理解，这样有利于干系人之间的沟通，协商等，因为每一个干系人对系统的关注点都不同
  • 软件架构提供了一种通俗的语言，方便对干系人不同需求的协商，使观点大致统一，而不是在后面的开发中才产生很大的分歧

• 早着手做设计决定

  • 软件架构实际上就是系统早期的设计决定，而且早期的这些决定往往对后续工作起着重要的作用，如果在后续工作中发现前期的架构设计有问题，往往是灾难性的，因为很多后来的决定都是在前面的决定的基础上做的。

• 作为后期实现的约束存在

  • 软件架构师在早期做软件架构的时候就权衡了各方面的因素，给出了明确的分工和定义，在实现的过程中，编码人员只需要完成规定的任务即可，至于部分和部分之间是如何交互的，则不需要考虑。
  • 同样的软件架构人员也不需要具体了解使用什么算法等一系列细化的问题，只需要确定大的方向和模块就行了。

• 对组织结构产生影响

  • 就像上一条说的那样，软件架构把系统分为不同的部分，每一块可以由指定的人负责，这样软件架构也就影响了组织结构。
  • 使用这种方法划分组织结构，有一点劣势就是负责摸个子系统的团队会拒绝参与其他团队的工作。

• 允许增量式原型

  • 一旦软件架构确定，就相当于划定了大致结构，好的开发方法是，根据架构进行增量式开发，首先不会过多的在意某一个功能方面的事情，而是功能和功能之间的交互，提供服务和接口等。
  • 这样做的好处是减少开发风险，同时，最初设定的架构框架也许可以在其他的某些系统的开发过程中重复使用

• 使对开销和时间的估计更加准确

  • 对于一个项目经理来说，准确的对整个项目进行估计，监控项目的开发情况是整个项目成功的关键
  • 作为软件架构师，帮助项目经理在项目开发的初期对项目的时间和费用开销有一个近似准确的估计是有必要的，通常项目的组织架构和WBS也是根据架构来制定的
  • 一般采用自顶向下和自下而上的方法对整个项目进行估计

• 提供一个可重用的模型

  • 就像代码重用会带来很大的好处一样，对有近似需求的系统进行架构的重用可以节省不少的精力
  • 一系列有近似需求的系统汇集起来，对他们公共重复的部分统一处理。也就是说项目不再作为一个独立的个体，而是最终把一系列相似的项目作为产品推出。

• 让彼此独立的元素进行合并

  • 软件架构对原本独立的元素统一管理，软件架构是站在整体的角度提出元素和元素之间的联系，使得系统中的组件不再是一个一个的独立的个体
  • 元素最终组成模块对外提供固定的接口，这样即使是内部进行改变也不会让所有调用它的模块都发生改变

• 固定几种架构模式

  • 作为架构来说，不是每一次开发都需要重新设计一个架构的，对系统的架构进行归类可以总结提炼出几种架构模式，这样在具体的解决问题的时候，就可以套用某中模式进行解决。
  • 这样有共性解决起来就没有那么复杂和困难。

• 帮助看清问题的本质

  • 当开发组来了新的成员的时候，软件架构可以清晰的告诉他元素之间是如何交互的，系统的功能点有哪些，同时在项目干系人之间也方便交流。