文章目录

• 一、名词定义
• 二、为什么需要软件架构设计
• 三、架构师的意义
• 四、架构设计
• • 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产品需求文档（完整的架构构思）

• 推荐书籍??《Software Architecture in Practice》

一、名词定义

• ADD定义：属性驱动设计(Attribute-Driven Design，ADD)。

• 软件架构定义：一个系统的软件架构是构成该系统所需结构的组合，它们由软件元素、元素之间的关系以及元素和关系两者的属性组成。

• 绿地系统，英文原文是greenfield system，指在少量代码或没有遗留代码的基础上开发的系统。

• 棕地系统，英文原文是brownfield system，指在遗留系统中进行的开发。

二、为什么需要软件架构设计

.架构会妨碍或支持系统质量属性的实现。
·在架构中做出的决定允许你在系统发展的过程中分析改变的原因并管理它们。
·对软件架构的分析使我们可以在系统开发的早期预测系统的质量。
·书面记录的架构加强了利益相关者之间的沟通。
·软件架构是最早的设计决策的载体，这些设计决策也是最基本、最难修改的。
·软件架构定义了一系列的约束条件以及后续的实现。
·软件架构会影响一个组织的结构，反之亦然。
·软件架构能够为可改进甚至是一次性的原型设计提供基础。
·软件架构是架构师和项目经理估算成本和进度的关键工件。
·软件架构可以作为一个可转移、可重复使用的模型，该模型可以构成产品线的核心。
·基于架构的开发专注于组件的组装，而不仅仅关注它们的创建过程。
·通过限制软件架构的备选方案，架构师可以激发开发人员的创造性，减少设计和系统的复杂度。
·软件架构可以为培养新的团队成员打基础。

三、架构师的意义

架构师在整个软件架构生命周期的活动，如下图所示：

4.2.1、架构设计（系统全景图）

Grady Booch曾经说过，“所有架构都是设计，但并非所有设计都是架构。”那么是什么让一个决策成为“架构”的呢strong>如果一个决策有非局部的影响并且会影响架构驱动因子的达成，我们就说它是架构的。因此，没有一个决策本质上就是架构的或 者非架构的。一个单个要素的缓冲策略的选择可能对系统的其他部分没有什么影响，在这种情况下它是一个实现细节，除了该元 素的实现者和维护者外没有人会关注它。

4.2.2、元素交互设计（业务流程设计）

根据系统的规模和复杂性，软件架构师应当参与元素的交互设计，无论是直接参与还是作为审计的角色参与。这种参与确保 了系统的重要质量属性没有妥协—例如，元素没有正确地被定义、定位或者连接。这也将有助于软件架构师发现泛化的机会

4.2.3、元素内部设计（详细系统设计）

架构的存在是为了帮助实现业务目标。 软件架构师应该清楚这些目标，沟通这些目标(和交涉这些目标!)并在设计过程开始前建立一个清晰的设计目标

4.2.4、场景（系统扩展范围）

在设计一个软件架构时，你为什么需要考虑主要功能有两个重要的原因:
1.你需要思考如何将功能分配到元素(通常是模块)来推进可修改性或可重用性，并计划工作任务。
2.一些质量属性场景直接与系统的主要功能相连。例如，对于一个电影流媒体应用程序，主要的用例之一当然是看电影。这 个用例可以与一个性能质量属性的场景关联，如“一旦用户按下播放键，电影应该在不超过5秒的时间内开始播放”。在这种情 况下，质量属性场景直接与主要用例关联，所以做出支持这个场景的决定同时也需要决定如何支持其相关的功能。并不是所有的 质量属性场景都像这样。例如，一个可用的场景可以涉及从系统故障中恢复，这种故障可能会发生在任何系统的用例正在执行 时。

4.2.5、参考架构

4.2.6.2、分层架构- 面向模式的软件架构

如何调研外部开发依赖组件的可用性：
·寻找的问题。这个问题是特定的吗，是针对关系映射面向对象的框架问题，还是一些更普遍的问题呢，如平台r> ·成本。许可证的成本是多少是免费的，支持成本和教育培训成本又是多少r> ·许可证类型。有和产品目标兼容的许可证吗r> ·支持。外部开发组件的支持如何关技术的扩展文档吗扩展用户或者开发 区，来寻求建议和帮助吗r> ·学习曲线。学习这个技术有多难在的团队组织是不是已经有人掌握了这项技术成的课程吗r> ·成熟度。这个技术是市场中新兴的吗会可能很新潮但是相对不太稳定或者没有支持呢r> ·流行度。这个技术是相对广泛传播的吗成熟的组织积极地推荐或者采纳吗具有该技术深度知识的人容易吗没有一个活跃的开发 区或者用户群体r> ·兼容性和集成的容易度。和其他运用在项目中的技术兼容吗这里插入图片描述
被容易地集成到项目中吗r> ·对关键质量属性的支持。这项技术对性能属性有限制吗又可靠吗r> ·规模。技术的应用会不会对开发的应用规模有负面影响p>

4.2.6.6、架构设计过程

概要设计

进度管理

4.3.2.3、约束条件（限制范围）

4.3.3.1、PRD产品需求文档（完整的架构构思）

参考：如何构建一个高可用架构

依据上面图，进行第二步操作，根据因子进行迭代目标。实际上这块我理解就是进行敏捷管理。