架构设计特点

       我们已经讲述了什么是架构，也定义了架构师这个角色的特点，下面我们来粗略讲述一下架构设计流程基础内容或特点。
       架构设计的范围相当广泛。下图显示定义软件架构设计流程不同方面的一个模型。

       这个模型取自于IEEE1471标准，总结如下：
1.一个系统拥有多个架构
2.一个系统实现多个任务
3.一个系统拥有一个或多个利益相关者
4.一个系统存在与一个环境
5.一个环境影响与一个系统
6.一个架构由一个架构描述描述
7.一个架构描述确定一个或多个利益相关者
8.一个架构描述确定一个或者多个关注点
9.一个架构描述提供基本原理
10.一个利益相关者拥有一个或者多个关注点
11.一个关注点对于一个或者多个利益相关者来说很重要
       除此之外，除了IEEE1471标准，上图还阐述一下标准：
1.一个开发项目由一个团队担任
2.一个开发项目遵循一个开发流程
3.一个开发项目开发一个系统
4.开发流程包括架构设计
5.团队包括一个架构师
6.架构师执行架构设计
7.架构师创建一个架构
8.架构师是利益相关者的一种
9.架构设计产生一个架构
10.基本原理验证一个或者多个架构决策
11.一个架构决策处理一个或者多个关注点

一、架构设计是一门科学
       架构设计是一门公认的学科，它正在慢慢成熟。架构师在开发一个架构时应寻找已验证的解决方案而不是重复发明，从而避免不必要的创造。在开发一个架构时，参考架构、建筑和设计模式，以及其他可重用资源方面的系统化经验也有一定的作用。
       然而，软件架构设计流程像土木工程中的流程一样，它在成熟之前仍然有一段路要走。这种成熟度可以从许多方面来考虑，包括标准的使用方法，以及对最佳方法、技术和流程的理解。

二、架构设计是一门艺术
       前面说架构设计是一门学科，其实也可以说它是一门艺术，因为在构建架构时还需要有一定程度的创造力，当处理新奇和没有先例的系统时尤其如此。在这些情况下，可以借鉴非系统化的经验。

       然而，在很大程度上，架构设计的艺术性还是很小的。即使是在最新颖的系统中，通常也是可以从其他地方找到解决方案的，或许只要将找到的解决方案稍微修改一下，就可以使其适应新的系统。

        随着软件架构设计流程越来越主流化，它已经不再被看作是只有极少数人能掌握的神秘方法了，而是有一定科学基础并被公认的一组定义良好且经过证实的方法，而且已被广泛接受。

三、架构设计跨越很多方面
       架构师参与软件开发流程中架构设计之外的许多方面：
1.架构师在需求方面提供帮助，例如，确保获取架构师特别感兴趣的那些需求
2.架构师参与排定需求的优先级
3.架构师参与实现，定义用于优化源代码及可执行工作产品的实现结构
4.架构师参与测试，确保结构可测试并被测试
5.架构师负责开发环境中定义一些项目标准及指导方针的一些工作
6.架构师帮助定义配置管理策略，因为配置管理结构经常反映已经定义的架构
7.架构师和项目经理紧密合作，架构师投入项目计划活动

四、架构设计是一个渐进的活动
       经验表明：架构设计不是项目早期一次性执行的一项活动。架构设计适用于项目的整个生命周期，随着一系列递增和迭代的可执行软件的交付，架构会变得越来越完善和稳定，那么，架构师在项目的生命周期中应该关注什么呢？我们一起来看看。

       下图表示随着时间的改变项目的重心所发生的变化。正是由于项目重心在变化，所以架构师的关注点也会随着时间的改变而改变。

       在项目早期，架构师主要关注于发现。重点是理解系统的范围、识别重要的特征及任何相关的风险，这些因素明显影响了架构。接着，关注重点会转向创造，这时，架构师最希望开发一个可以为完全实现系统提供基础的稳定架构。在大部分发现和创造都已经实现后，关注重点将变为实现。
       从上图可以看出应该注意的是，对发现、创造和实现关注的顺序并不是严格不变的。在项目早期，在构建架构原型时就会有一些实现，在项目后期，在接受一些教训后，也会有一些新发现，用于实现架构特定元素的不同策略。
       在系统交付之前架构设计的流程一直都不会结束，因此，直至项目结束，架构师都必须参与其中。很多组织经常强烈期望在架构稳定时把架构师从项目中移走，以便把这个宝贵的资源用于其他项目上。事实上，在项目后期仍然需要进行架构决策的。
       所以我们经常会发现这样一个情况：在影响架构的主要决策制定完之后，架构师成为团队的兼职人员。这也算是一个妥协的办法吧！不管怎样，架构师不应该完全脱离。当架构师的角色由一个团队来担任时，就灵活多了，其中部分成员可以去负责其他项目，只要留下来的成员继续确保系统的架构完整性即可。

五、架构设计受到许多利益相关者驱动
       一个架构实现许多利益相关者的需要。因此，架构设计的流程必须考虑所有的利益相关者，以确保他们的关注点（尤其那些可能对架构有影响的关注点）都被捕获、阐明、协调及管理。所以，让利益相关者参与对这些关注点解决方案的复审也很有必要。
       考虑所有的利益相关者的要求对于确保生成一个成功的架构来说非常重要。这些利益相关者影响着架构设计流程的许多方面，例如，需求的采集方式、架构文档编写方式及架构的评定方式等。

六、架构设计经常包括折中
       既然有这么多因素影响着一个架构，那么，架构师肯定经常需要在冲突的需求之间进行权衡了，以便找到合适的折中方案。例如，考虑是使用这种技术还是那种技术，是使用这个第三方组件还是另一个第三方组件，包括使用模式的选择。
       进行折中权衡并不是架构师应该或能够避免的事情。架构师应该进行有选择地考虑，并且，在各种选择中进行折中是架构设计流程的基本方面。
       下图是对解决方案架构设计中一些影响因素的简单分类。

       除了系统提供的功能外，还必须关注非功能性需求，包括运行期质量（如性能和可用性）、非运行期质量（如可维护性和便携性）、业务约束（如规章制度约束和资源约束）及技术约束。

七、架构设计承认经验
       架构师很少是从一张白纸开始做起的。正如先前所述，他们会积极地寻找那些可以使用的架构模式、设计模式、现有组件等。换句话说，架构师要努力寻找可重用的资源。
        可重用资源是对重复出现问题的解决方案，可重用资源是牢记在头脑中的已经开发过的资源。一个架构的元素在当前系统的上下文中是可以重用的，同时，架构师还会把他们的架构或架构的元素看作是可以在当前系统之外可以重用的资源

八、架构设计既由上而下也由下而上
       通常，在进行架构设计时会采用由上至下的设计方式，也就是先是获取利益相关者的需求，再架构定义之前了解的需求，然后设计架构元素，最后实现这些元素。
       然而，很少有架构是完全由上至下驱动的。主要原因是大部分系统并不是完全从头开始的，通常会有一些遗留产品以必须采纳且影响这种架构的现有解决方案元素的形式存在。这些元素包括完全重新开发的应用，以及约束这种架构的委托设计或委托实现元素等。
        成功的架构师在进行架构设计时既会由上而下，也会由下而上，可以将这两种方式看作是架构设计“中间相会”的方式。