- 一、名词定义
- 二、为什么需要软件架构设计
- 三、架构师的意义
- 四、架构设计
- 4.1、通用设计
- 4.2、软件架构的设计
- 4.2.1、架构设计（系统全景图）
- 4.2.2、元素交互设计（业务流程设计）
- 4.2.3、元素内部设计（详细系统设计）
- 4.2.4、场景（系统扩展范围）
- 4.2.5、参考架构
- 4.2.6、架构的设计模式
- 4.2.6.1、分层架构-结构化架构描述
- 4.2.6.2、分层架构- 面向模式的软件架构
- 4.2.6.3、部署模式-应用架构
- 4.2.6.4、架构的设计策略
- 4.2.6.5、外部依赖组件
- 4.2.6.6、架构设计过程
- 4.2.6.7、系统类型设计图
- 4.2.6.7.1、现存系统设计
- 4.3、商用案例
- 4.3.1、社会现象
- 4.3.2、系统需求
- 4.3.2.1、用例模型
- 4.3.2.2、模型场景抽取
- 4.3.2.3、约束条件（限制范围）
- 4.3.2.4、架构概要分析和设计
- 4.3.3、设计过程
- 4.3.3.1、BRD业务需求文档（关键业务提取）
- 4.3.3.1、PRD产品需求文档（完整的架构构思）
- 来源《软件架构师设计12项原则》读书笔记
- 推荐书籍《Software Architecture in Practice》
-
ADD定义：属性驱动设计(Attribute-Driven Design，ADD)。
-
软件架构定义：一个系统的软件架构是构成该系统所需结构的组合，它们由软件元素、元素之间的关系以及元素和关系两者的属性组成。
-
绿地系统，英文原文是greenfield system，指在少量代码或没有遗留代码的基础上开发的系统。
-
棕地系统，英文原文是brownfield system，指在遗留系统中进行的开发。
.架构会妨碍或支持系统质量属性的实现。
·在架构中做出的决定允许你在系统发展的过程中分析改变的原因并管理它们。
·对软件架构的分析使我们可以在系统开发的早期预测系统的质量。
·书面记录的架构加强了利益相关者之间的沟通。
·软件架构是最早的设计决策的载体，这些设计决策也是最基本、最难修改的。
·软件架构定义了一系列的约束条件以及后续的实现。
·软件架构会影响一个组织的结构，反之亦然。
·软件架构能够为可改进甚至是一次性的原型设计提供基础。
·软件架构是架构师和项目经理估算成本和进度的关键工件。
·软件架构可以作为一个可转移、可重复使用的模型，该模型可以构成产品线的核心。
·基于架构的开发专注于组件的组装，而不仅仅关注它们的创建过程。
·通过限制软件架构的备选方案，架构师可以激发开发人员的创造性，减少设计和系统的复杂度。
·软件架构可以为培养新的团队成员打基础。
架构师在整个软件架构生命周期的活动，如下图所示：
架构师需要角色能力：
·领导力:工作指导、团队建设、建立愿景、组织培训。
·沟通:技术和非技术的沟通、鼓励合作。
·谈判:处理内部和外部的利益相关者和他们之间相互冲突的需求和期望。
·技术技能:生命周期技能、专业技术知识、持续学习、编码能力。
·项目技能:预算、人员、进度管理、风险管理。
·分析能力:软件架构分析、项目管理和测量的常规分析思维(参看下面的引文“分析的含义”)
设计是一个动词，也是一个名词。设计是一个过程，一个活动，因此可以被看作是一个动词。该过程的结果是创建一个设计 —一个对理想的最终状态的描述。因此，设计过程的输出是一件事物、名词，是你最终会实现的产品。设计意味着做出决策来 达到目标并满足要求和约束。设计过程的输出是这些目标、要求和约束的直接反映。例如，我们可以参考一下房子是如何设计 的。为什么中国传统民居的外观不同于瑞士或阿尔及利亚的?为什么蒙古包看起来像蒙古包，而不同于雪屋或者木屋呢?
4.2、软件架构的设计决策来把设计的目的、需求、约束和架构方面关心的问题(我们称之为架构驱动因子)，转化为结构，并用来指导项目，指导成本和进度的评估、团队的形成、分析和降低风险。
因此，软件架构设计是一个实现产品和项目目标的关键步骤。
Grady Booch曾经说过，“所有架构都是设计，但并非所有设计都是架构。”那么是什么让一个决策成为“架构”的呢? 如果一个决策有非局部的影响并且会影响架构驱动因子的达成，我们就说它是架构的。因此，没有一个决策本质上就是架构的或 者非架构的。一个单个要素的缓冲策略的选择可能对系统的其他部分没有什么影响，在这种情况下它是一个实现细节，除了该元 素的实现者和维护者外没有人会关注它。
4.2.2、元素交互设计（业务流程设计）根据系统的规模和复杂性，软件架构师应当参与元素的交互设计，无论是直接参与还是作为审计的角色参与。这种参与确保 了系统的重要质量属性没有妥协—例如，元素没有正确地被定义、定位或者连接。这也将有助于软件架构师发现泛化的机会
4.2.3、元素内部设计（详细系统设计）架构的存在是为了帮助实现业务目标。 软件架构师应该清楚这些目标，沟通这些目标(和交涉这些目标!)并在设计过程开始前建立一个清晰的设计目标
4.2.4、场景（系统扩展范围）
针对响应度量场景来说，可以通过效用树来进行分解
在设计一个软件架构时，你为什么需要考虑主要功能有两个重要的原因:
1.你需要思考如何将功能分配到元素(通常是模块)来推进可修改性或可重用性，并计划工作任务。
2.一些质量属性场景直接与系统的主要功能相连。例如，对于一个电影流媒体应用程序，主要的用例之一当然是看电影。这 个用例可以与一个性能质量属性的场景关联，如“一旦用户按下播放键，电影应该在不超过5秒的时间内开始播放”。在这种情 况下，质量属性场景直接与主要用例关联，所以做出支持这个场景的决定同时也需要决定如何支持其相关的功能。并不是所有的 质量属性场景都像这样。例如，一个可用的场景可以涉及从系统故障中恢复，这种故障可能会发生在任何系统的用例正在执行 时。
参考架构是一个蓝图，它为特定类型的应用程序提供一个整体的逻辑结构。参考架构是一个映射到一个或多个架构模式的参 考模型。
策略类别专门针对质量属性的可用性、互操作性、可修改性、性 能、安全、可测试性、可用性。
如何调研外部开发依赖组件的可用性：
·寻找的问题。这个问题是特定的吗?例如，是针对关系映射面向对象的框架问题，还是一些更普遍的问题呢，如平台?
·成本。许可证的成本是多少?如果是免费的，支持成本和教育培训成本又是多少?
·许可证类型。有和产品目标兼容的许可证吗?
·支持。外部开发组件的支持如何?有相关技术的扩展文档吗?存在扩展用户或者开发社区，来寻求建议和帮助吗?
·学习曲线。学习这个技术有多难?你所在的团队组织是不是已经有人掌握了这项技术?有现成的课程吗?
·成熟度。这个技术是市场中新兴的吗?会不会可能很新潮但是相对不太稳定或者没有支持呢?
·流行度。这个技术是相对广泛传播的吗?有被成熟的组织积极地推荐或者采纳吗?雇用具有该技术深度知识的人容易吗? 有没有一个活跃的开发社区或者用户群体?
·兼容性和集成的容易度。和其他运用在项目中的技术兼容吗?能在这里插入图片描述
被容易地集成到项目中吗?
·对关键质量属性的支持。这项技术对性能属性有限制吗?安全又可靠吗?
·规模。技术的应用会不会对开发的应用规模有负面影响?
依据正在设计的架构系统类型，可能会存在一个“最优的”—或者至少是值得强烈推荐 的—需要被排列好的迭代目标的优先级顺序。例如，在一个成熟领域内的绿地系统，你的初始目标一定是通过选择一个参考架 构，为系统确定一个综合性的结构。
理想情况下，对每一个被作为输入组成之一的驱动因子，你都要执行额外的迭代并重复执行步骤2~7。
是否需要更多的设计迭代，评估的标准是什么?可以让风险来指导我们。我们至少应该找到高优先级的驱动因子
软件系统的设计分为三大类:1一个成熟领域内的(如众所周知的)绿地(greenfield)系统设计;2一个新领域内的(如 一个基础设施和知识基础都不太成熟的领域)绿地系统设计;3对现有系统进行更改的设计(棕地，brownfield)。在目标序 列中，每一个类型都涉及不同的路线图，而这个路线图序列是你应该在设计迭代过程中执行的。
4.2.6.7.1、现存系统设计看清楚
在开始设计迭代之前，你的第一个目标应该是确保有一个对现有系统架构的清晰认识。
识别和选择
戴森(Freeman Dyson，英国物理学家)曾说:“一个好的科学家是一个有创意的人。一个好的工程师则是一个尽量少用 原创思想来做设计的人。”这段名言和软件架构设计的概念有很大的关联:大多数情况下，你不需要也不应该“重新发明轮 子”。相反，你主要的设计活动是识别和选择设计概念，来解决在设计迭代中遇到的挑战和驱动因子。设计始终是一个原始的又 有创造性的尝试，不过我们将创造力保留在对现存解决方案恰当的识别中，然后结合、调整手中的问题。
架构师的识别和选择
·利用现有的最佳实践。可以通过使用已出版的或在线形式的可用目录，识别你所需要的替代型设计概念。有的设计概念， 如模式，已经被广泛地记录了;其他的，如外部开发组件，被一种不太完善的方式记录了下来。这个方法的好处是你可以识别多 个备选设计概念，并且可以利用其他丰富的知识和经验。缺点是，寻找和研究信息需要大量的时间，所记录的知识的质量往往是 未知的，并且作者的假设以及偏见也都是未知的。
·利用你自己的知识和经验。如果你设计的系统和你过去设计的其他系统类似，你可能会想从你以前用过的设计概念开始。 这个方法的优点是对于备选设计概念的识别实施起来既快速又可信。缺点是，你或许会重复使用某些相同的想法，即使它们不是 你所面临的所有设计问题中，最适合的设计概念，并且如果它们已经被更好的方法替代了。俗话说:“如果你给小孩一把锤子， 对这个孩子来说，全世界都变得像钉子一样。”
·利用其他人的知识和经验。作为一个架构师，你有这些年获得的背景和知识。人与人之间的基础不同，特别是当有人过去 已经处理过该类型的设计问题时。你可以利用这些信息，通过实施识别和筛选你同行头脑风暴后得出的设计概念。
时序图来帮助我们梳理现有类和业务流程关系
架构设计
在早期阶段，架构是抽象的，某些信息是不重要的可以过滤掉
概要设计
将草图和想法，分析，阐述和教育的内容进行留存，随着深入的理解不断加深和演变。
进度管理
比如我们根据社会现象发现了一些重复的工作或者一些非常耗费人力成本的问题。
4.3.2、系统需求通过需求抽取，最密切相关的需求进行优先级排序，寻找我们的核心需求。
4.3.2.1、用例模型通过需求抽取，我们可以进行用例区分，用例和描述
这里需要跳到4.2软件架构的设计。进行4.2.6架构设计模式的工作。
4.3.3、设计过程从需求和业务关注点出发，跨越到设计领域。对于架构师来说，最重要的工作是将需求转化成设计决策。
作为架构师最核心的部分:做出对后续行动具有深度影响的决策。
参考：如何构建一个高可用架构
依据上面图，进行第二步操作，根据因子进行迭代目标。实际上这块我理解就是进行敏捷管理。
