第三章 软件架构产生的背景

从技术方面说软件架构(technical)

• 在技术方面，软件架构为系统提供了一系列的可选的质量属性，可以完全通过软件架构就知道系统拥有的属性有哪些，而不是具体等到实现了以后才知道。
• 要根据现在的科技大环境来选择所使用的技术，比如，如果现在需要我们设计一个系统架构，首先就需要确定是基于WEB开发，面向对象，面向服务，移动端的还是基于云平台的，可能过了几年又会出现新的技术来代替这些现有的技术。

从项目的生命周期说软件架构(Project Life-Cycle Context)

• 计划软件开发过程是具体开发系统的基础，软件开发过程会具体的告诉开发人员下一步应该做什么，常见的软件开发过程如下：
  • Waterfall 瀑布开发
  • Iterative 迭代开发
  • Agile 敏捷开发
  • Model-driven development 模块驱动开发
• 以上所有软件开发过程都涉及到到了对软件架构的设计，所以不管在软件的生命周期中使用以上哪种开发过程，构建一个软件架构都需要以下一系列步骤，而不同的开发过程只是在检查和评审周期上不同，构建软件架构中的步骤包括：
  • 为系统制定一个业务实例
  • 理解在架构方面的具体需求
  • 创建一个新的架构或者选择一个已经存在的架构
  • 记录和讨论架构
  • 分析和评价架构
  • 基于架构实现和测试
  • 确保整个开发过程是基于架构的

从商业层面说软件架构(Business)

• 开发一个系统的初衷就是为了满足一个或者多个组织的商业目标，架构师当然就需要了解所有干系人不同的需求，在最大程度上满足的同时进行权衡。

  Business Goals—>Quality
  Attributes—>Architecture
  Business Goals—>Architecture

  也就是说商业目标可以通过影响系统质量的属性来影响架构，也可以直接影响架构

• 架构和组织的结构的关系

  • 一个组织通常会有一些现存的架构和基于这些架构开发的实例，这样这个组织就会倾向于接和之前开发过的系统类似的项目，提高架构的重用率减少开销。
  • 另外，一个组织可能会制定一个长期的商业目标，之后就为了这个商业目标设定一个小组的人，对基础设备进行建设。
  • 最后，组织结构和软件架构互相影响，组织一般都会按照技术职能进行划分，比如前端，后台，数据库等等，所以在对软件架构中的子系统的开发可能就会创建出一个以该子系统命名的开发小组。

从专业层面来说软件架构(Professional)

• 作为一个软件架构师不仅需要专业的知识，更多的经验和协商交流的技巧，来更好的满足干系人的需求

架构是如何被影响的

• 上面说的Business，Technical，Project，Professional这四个最终都会对软件架构师产生影响，而软件架构师又决定最终的架构。
• 其中除了Professional这个是关于软件架构师的专业水平和之前积累的经验外，剩下的三个因素都首先会对干系人产生影响，而后干系人再对软件架构师产生影响。

架构会影响什么

• 就像前面说的那样，Business，Technical，Project，Professional这四个因素会对软件架构产生影响，然而其实软件架构反过来也会影响这四个因素。

  • Technical
    在软件架构师根据干系人在技术方面的要求设计出了系统的软件架构后，干系人可能会根据当前的软件架构提出修改的意见，这样就间接的影响了Technical。

  • Project
    通常会根据软件架构来对开发组进行划分，对工作进行分配，这样软件架构就影响了项目的组织和划分。

  • Business
    通过这次架构的设计完全有可能会影响后来公司整体的商业方向。

  • Professional
    软件架构师通过这次对该系统进行架构设计，积累了经验，丰富了自己的业务知识。

• 这种反馈机制被称为Architecture Influence Cycle，即AIC，简单的说就是Business，Technical，Project，Professional这四个因素会影响软件架构的诞生，而软件架构的诞生反过来又会影响软件架构师，组织结构，性能和整个产业。