架构设计最佳实践的笔记，BEA经验丰富的架构师多年的积累（强烈推荐，不可错过）

有幸请到BEA的架构设计师刘杰给公司做了一次为期2天的架构最佳实践培训。个人印象来说，这次培训含金量比较高，讲师有非常多年的实际架构设计经验，且目前一直在做架构。讲的东西都是贴切实际，带来很多经验，和一些新的概念。下面是我在课堂上做的一些笔记，主要记录了一些新的概念和老师的一些经验。

 

关于软件架构的定义：
  一系列重要决策的集合、多个结构的组成

软件架构视图必不可少，是因为各类涉众需要从各自的角度去理解和使用架构

软件架构四要素
1. 图示化元素与元素之间的关系
2. 有明确的图例，定义和说明元素
3. 元素明确的接口和行为规范
4. 设计原理和决策

 

软件架构的图要根据行业背景不同，画别人能理解的图。

4+1 Vies Model
逻辑视图(Logical View)、开发视图(Development View)、运行时机构图(Process View)、物理视图或部署图(Physical View)，这些图像都需要放到实际的场景（Scenarios）中去验证，没有在实际的场景中验证的都是一些很虚的东西。

 

软件架构的目的：

是为了按照设计师的思想执行，是最初设计的决策体系、是风险承担者、相互交流的手段、是系统可重用、可传递的规则。

一个架构师一定要清晰的表达架构的目的，如果不能清晰的表达出来，就等于没有做架构一样。

 

架构的三个境界
1. 要做出架构
2. 表达架构的意思
3. 能使别人理解，并遵循架构。

 

常见的架构视图类型
功能视图、开发视图、进程视图（Run Times时期）、部署图、场景图、数据视图（大数据量、大并发量）、实现视图

数据模型（领域模型）很重要，由架构师负责设计全局的领域模型，一般来说数量大概在50-100个左右。

数据模型的选择会影响最终系统灵活性，数据模型设计好了，系统的扩展性、灵活度会高一些。

 

软件架构的试图中，对具有风险性的、用户最关心的图需要重点分析。

 

软件架构的驱动因素
过去我们的软件架构中都是由软件的功能和技术做为整个软件架构的驱动，但是到了后期会出现一系列问题，有些问题是之前未考虑到的，有些或是其他原因，目前软件架构要在功能、质量属性、约束三个方面做为软件架构的驱动力。也就是做架构的时候要在功能、质量属性、约束这三个方面考虑，而不是传统的只考虑功能和技术。比如一个MP3播放器，爱国者的和APPLE的都是能播出MP3,也就是功能是实现了，但是价格为什么相差那么大呢，也就说我们考虑架构不单是要考虑功能、还有质量属性，还有约束条件，东西做出来了，使用的人不会用，那也是白搭。软件的使用中受到那些约束环境，如行业标准、政策、遗留系统、环境条件、用户水平、组织结构等，这些都是在架构设计时候需要考虑的东西。

功能 - 关键业务场景
质量属性 - 开发时的质量属性、运行时的质量属性、商业质量属性
约束 - 客户需求以及业务相关约束、用户以及使用环境相关约束、开发组织以及开发环境相关约束。

 

架构师的考核能力，可以列举一系列坏的设计（坏症状）出来，然后一条条照套。