Software Architecture DocumentVersion Revision HistoryDate Version Description Author Version: Software Architecture Document Date: Page 2 of 18目录1. 文档简介 41.1 文档目的 41.2 文档范围 41.3 定义、缩写词和缩略语 41.4 参考资料 42. 架构描述方式 42.1 架构视图阅读指南 42.2 图表与模型阅读指南 53. 架构设计目标 53.1 关键功能 53.2 关键质量属性 53.3 业务需求和约束因素 54. 架构设计原则 64.1 架构设计原则 64.2 备选架构设计方案及被否原因 64.3 架构设计对后续工作的限制（详设，部署等） 65. 逻辑架构视图 65.1 职责划分与职责确定 75.2 接口设计与协作机制 85.3 重要设计包 106. 开发架构视图 116.1 Project 划分 116.2 Project 1 116.2.1 Project 目录结构指导 126.2.2 程序单元组织 126.2.3 框架与应用之间的关系（可选） 126.3 Project 2 136.4 Project n 137. 运行架构视图 137.1 控制流组织 137.2 控制流的创建、销毁、通信 137.3 加锁设计 148. 物理架构视图 148.1 物理拓扑 148.2 软件到硬件的映射 15 Version: Software Architecture Document Date: Page 3 of 188.3 优化部署 169. 数据架构视图 169.1 持久化机制的选择 179.2 持久化存储方案 179.3 数据同步与复制策略 1710. 关键质量属性的设计原理 17 Version: Software Architecture Document Date: Page 4 of 181. 文档简介帮助读者对本文档建立基本印象，并为阅读后续内容扫清障碍。1.1 文档目的文档目的，非项目目的。否则造成同一项目多个文档之间的内容重复，不利于文档维护。本小节应指明文档针对的读者对象，最好列出各种读者角色，并说明每种读者角色应该重点阅读的章节。1.2 文档范围文档的 Scope，非项目的 Scope。否则造成同一项目多个文档之间的内容重复，不利于文档维护。1.3 定义、缩写词和缩略语集中列举文档中的定义、缩写词和缩略语。1.4 参考资料本项目经审核的计划书、合同、上级批文；本项目的其他已发表文件；本文档引用的文件资料，如软件开发标准。具体而言，应包括参考资料的题目（必须）、编号、版本号（必须）、发表日期、发布方，必要时还可以说明如何使用这些资料。2. 架构描述方式 为了让读者更好地理解架构文档 ，在本节应当说明文档涉及的架构视图，并指明为了描述设计决策用到了哪些图表和模型。2.1 架构视图阅读指南以多视图的方式来组织架构文档 是大势所趋。ADMEMS 推荐的是经过优化的 5 视图方法，如下图所示。 Version: Software Architecture Document Date: Page 5 of 182.2 图表与模型阅读指南对后续文档内容中所用到的建模语言（例如 UML）、表格（例如目标-场景- 决策表）等进行说明。3. 架构设计目标功能、质量、约束，一个都不能少。3.1 关键功能对架构设计至关重要的功能，包括如下 4 类：核心功能、必做功能、高风险功能、独特功能。所谓独特功能，指这个功能覆盖了上述 3 类功能没有涉及到的职责。3.2 关键质量属性人之所以痛苦，很多时候是因为追求错误的东西。下图是 ADMEMS 方法确定关键质量的 5大原则的整体思路图。3.3 业务需求和约束因素ADMEMS 方法创造性地提出约束需求的 4 大类型，这是一种极为实用的分类方式。特别是业务需求对架构设计而言是一种约束的观点，解决了很多架构师的现实困惑。下图标明了 4 类约束在“需求层次-需求方面矩阵（又称 ADMEMS 矩阵）”中的位置，可以帮助我们理解产生约束需求的根源。 Version: Software Architecture Document Date: Page 6 of 184. 架构设计原则投标时经常讲“架构设计原则 ”，但到了架构文档，这些着眼大局的考虑却“丢了”。ADMEMS 方法推荐的本文档模板，认为应当把它们“找回来”。4.1 架构设计原则着重描述重大的权衡取舍考虑。4.2 备选架构设计方案及被否原因在概念架构一级，对备选架构设计方案进行描述，并阐述它们未被采用的原因。这有利于团队了解当前架构设计方案的来龙去脉，提高团队对当前架构设计方案的认可度。4.3 架构设计对后续工作的限制（详设，部署等）架构设计不仅应该包含“指导 ”，也应该包含重要的“限制”。例如，一份只是说明“性能和可扩展性都重要”的架构文档，实际上忽视了“可扩展性和性能之间存在的矛盾关系”。此时，最有效的办法就是在架构文档中明确说明“任何提升可扩展性的架构设计和详细设计，都应通过架构团队的评审才能引入，以确保性能目标不受重大影响”。5. 逻辑架构视图 关注点：此架构设计视图的关注点是职责划分。注意：逻辑架构视图无疑是最重要的，但同时也应避免“架构 = 模块 + 接口”等以偏概全的认识。参考：任何复杂系统的架构设计都不是一蹴而就的，所以架构师需要理性思维过程的指导。针对逻辑架构设计这个关键环节，一线架构师实践指南一书给出了 2 条建议：一是“以质疑驱动的螺旋思维”，二是相对分离地考虑“结构方面的切分”和“行为方面的定义”。下图所示即为 ADMEMS 方法推荐的逻辑架构设计理性思维过程。 Version: Software Architecture Document Date: Page 7 of 185.1 职责划分与职责确定内容：将系统切分成更小的单元，并明确这些单元的职责。具体而言，职责单元可以是层、子系统、模块、关键类等。意义：一句话，职责划分不合理，功能和质量都会受到影响。也就是说，功能需求和质量需求无一不和职责划分相关：一方面，每个功能都是由一条职责协作链完成的；另一方面，职责划分方式也影响着质量，于是需要职责模型针对特定质量属性要求做出相应调整和优化。很多人认为架构设计就是职责划分的艺术，虽略显片面，但足以表明职责划分的重要性。参考：基于对业界大量案例的研究，ADMEMS 方法梳理出了“模块划分的 3 种必用手段”，如下图所示，更多内容可参考一线架构师实践指南一书。 Version: Software Architecture Document Date: Page 8 of 185.2 接口设计与协作机制内容：本节描述接口的定义，以及协作的方式和规范。意义：恰恰是因为有了各模块之间“未来合作的契约”，分头开发各模块才有了基本保证。参考：ADMEMS 方法推荐利用 “包-接口”图，来识别接口。下图为一个“包-接口”图的示例。 Version: Software Architecture Document Date: Page 9 of 18参考：ADMEMS 方法推荐使用序列图，建议少用、甚至杜绝使用协作图。下图为一个序列图的示例。 Version: Software Architecture Document Date: Page 10 of 185.3 重要设计包内容：对重要子系统的设计进行“灰盒”级描述。意义：“每个子系统在架构设计中都应保持黑盒子 ”的观点，过于理想化了。对于业务层、通用协作机制而言，经常需要在架构设计期间就引入“灰盒”级描述。参考：类图和灰盒包图，在本节中较多出现。下图为一灰盒包图示例。 Version: Software Architecture Document Date: Page 11 of 186. 开发架构视图关注点：此架构设计视图的关注点是程序单元组织。注意：此架构设计视图是必须的、不应“剪裁”掉的。但实际情况却是，很多架构师不关注开发架构视图，导致很多程序开发人员抱怨“架构师就知道高来高去，架构对编程工作没什么指导性”。6.1 Project 划分内容：本节说明整个系统将划分成哪几个 Project 来开发，其中，Project 指开发环境所感知到的“工程”。意义：基本好处是，有利于开发的组织；而对一些大型的集成系统而言，由于同时涉及了Web 应用、桌面应用、嵌入式应用等软件形态，所以此时 Project 划分其实是不得不做的；最后，我们推荐核心代码应主动地切分到单独的 Project 以进行独立的软件配置管理（ SCM），以降低核心代码外泄的风险。参考：Project 划分必然是属于 “架构设计”的工作，严格来讲仅靠“需求分析”划分的业务域（Business Area）直接映射到 Project 经常意味着工作内容的遗漏。其实，业界不少有见地的专家已经认识到 WBS（工作分解结构）做得太早太草率危害很大，就与“Project 划分不到位”不无关系。 6.2 Project 1内容：对 Project 划分后的每个 Project 进行目录结构、程序单元组织、框架与应用关系的说明。 Version: Software Architecture Document Date: Page 12 of 186.2.1 Project 目录结构指导内容：关于该 Project 一级目录、二级目录等基本目录结构的约定。意义：为团队并行开发提供必要基础，让不同程序小组看到自己应该负责的程序目录。参考：不要把所有程序目录的约定都定义得太细，否则这份架构文档就要天天更新了。 6.2.2 程序单元组织内容：源码、程序库、框架、目标码等类型程序单元之间的编译依赖关系。意义：或许有人认为这没什么技术含量，但架构设计本来就不是只关心技术含量最高问题的。君不见，很多软件工程师跳槽到新的企业之后，竟然连一个能正常编译源码的开发环境都建不起来其实，他们“不知道 Project 所依赖的 Library 有哪些”是其中重要原因这本应在架构文档中给出明确描述的。 6.2.3 框架与应用之间的关系（可选）内容：框架（Framework）。意义：既然不适用 Framework 的开发越来越少了，既然程序员犯的很多错误都和对Framework 理解不到位有关，架构师就有责任明确说明 Framework 和待开发系统之间的关系。 参考：下图描述了 JGraph 框架和待开发应用的关系。 参考：下图描述了 Struts 框架和待开发应用的关系。 Version: Software Architecture Document Date: Page 13 of 186.3 Project 2内容：对 Project 划分后的每个 Project 进行目录结构、程序单元组织、框架与应用关系的说明。6.4 Project n内容：对 Project 划分后的每个 Project 进行目录结构、程序单元组织、框架与应用关系的说明。7. 运行