关键需求决定架构
架构师没有必要对所有需求都深入了 解，这是策略。
• 1. 功能需求数量众多，应该控制架构设计 时需要详细分析的用例的个数。
• 2. 不同质量属性之间往往是相互制约的， 这时需要一个权衡。
关键需求决定架构有利于集中精力深 入分析最重要的需求。
多视图探索
• 分而治之。这样可以在每种视图时专注系统 的某一方面。
分而治之的两种方式
面对一个复杂的问题，当如何进行分而 治之呢？
• 一、先不把问题研究得那么深，那么细，浅 尝辄止，见好就收。这种分而治之的方式称 为“按问题深度分而治之”。
• 二、先不研究整个问题，而是研究问题的一 部分，分割问题，各个击破。这种分而治之 的方式称为“按问题广度分而治之”。
分而治之的两种方式
• 另一方面，因为架构中包含了关于各元素应 该如何彼此交互的信息，所以可以把不同的 模块分配给不同的小组分头开发，架构在中 间扮演‘桥梁’和‘合作契约’的作用。
软件架构是团队开发的基础
• 这两方面是相辅相成的关系。具体而言，正 因为软件架构是大规模开发的基础，所以架 构中应包含软件系统的各元素如何彼此相关 的设计决策;也正是因为软件架构中包含了软 件系统如何组织等关键决策，才使得它能够 成为大规模开发的基础。
如何进行成功的架构设计
• 5.从物理角度，可以进行明确、灵活的部署 规划。还往往涉及到可移植性、可伸缩性、 持续可用性和互操作性等大型企业软件特别 关注的质量属性的架构策略。
成功的架构设计的关键要素
• 1.是否遗漏了至关重要的非功能性需求。 客户不仅关心功能的实现，更关心功能
实现的好坏， 5秒打开一个网页和10秒打开 一个网页对客户来说意义有时是完全不一样 的。很多项目甚至产品功能性的需求都实现 了，最后却栽倒在非功能性的需求上。
• 把设计搞得玄而又玄的结果是，很多影响全局 设计决策本应由架构设计来完成，却统统“漏” 到了后边，最终到了大规模并行开发阶段才发 现。这样，造成了“程序员碰头儿临时决定”的 情况大量出现，软件质量必然下降，甚至还会 导致项目失败。
• 那么，软件架构到底要设计到什么程度？
架构设计到什么程度
• 分而治之的两种方式 • 架构设计与详细设计 • 软件架构是团队开发的基础 • 架构要进行到什么程度
* 团队成员对架构师意见很大，团队士气受 到打击。
高来高去式架构设计常见症状
• 症状一：缺失重要架构视图。为了给团队 的不同角色提供切实的指导，软件架构师 应从不同视图进行架构的设计和归档。如 果忽视了在某重要架构视图方面的设计， 就会遗漏重要设计决策，具体的开发工作 将会陷入缺乏应有指导和限制的困境。
如何进行成功的架构设计
• 3.从运行角度，对系统的动态运行有良好的 规划，可以标识出哪些是主动模块，哪些是 被动模块，面向对象中往往是主动类和被动 类，明确这些模块之间的调用关系和加锁策 略，并说明关键的进程、线程、排队、消息 等机制；
• 4.从数据角度，对数据进行了良好的规划， 不仅包括数据的持久化存储方案，还可能包 括数据传递、数据复制、数据同步等。
• 架构设计并非“好的就是成功的”，而是“适 合的才是成功的”。
如何进行成功的架构设计
通过对架构进行的5种视图的角度来看 ，一个优秀的架构应该具有以下特点：
• 1.从开发角度，应该有良好的模块化，每个 模块职责清晰，模块之间松耦合，模块内部 高聚合并合理实现了信息隐藏；
• 2.从逻辑角度，适应了功能需求的变化，适 应了技术的变化。典型地，应该保持应用相 关的模块和领域通用模块的分离，技术平台 相关模块和独立于具体技术的模块相分离， 从而达到“隔离变化”的效果；
尽早验证
一般有两种验证方式
• 1. 原型方式。通过开发一个垂直演进原型 ，来实现软件架构。
• 2. 框架方式。或者说框架 + 垂直抛弃原型 。
架构设计到什么程度
• 我们发现架构设计方案往往是高来高去，造成 不同的人有不同的理解，而且实际的开发工作 还是得不到足够的指导，高技术风险依然大量 存在。
• 总之，这种先确定软件架构，而后基于软件架 构进行并行开发的做法，综合利用了两种分而 治之的方法，利于控制复杂性ቤተ መጻሕፍቲ ባይዱ提高开发效率 。这是一种值得推崇的开发方式，常被称为“以 架构为中心的开发方法”。
架构设计与详细设计
软件架构是团队开发的基础
• 一方面，架构从大局着手，就技术方面的重 大问题作出决策，构造一个具有一定抽象层 次的解决方案，而不是将所有细节全部展开 ，从而有效的控制了‘技术复杂性’。
成功的架构设计的关键要素
• 2. 能否适应频繁的需求变更，找出关键需 求来决定架构。
分离变化点。架构应该能够支持业务 功能在一定范围内变化。
• 3. 运用多视图，不同的视图是否一致、同 步。
架构师应该掌握趋于系统化的方法， 在分而治之的大前提下，也要注意综合考 虑，注意各个视图之间的同步。
• 4. 架构是否及时得到验证。
架构设计到什么程度
• 架构设计对软件的不同部分的设计程度并 不是整齐划一的。例如，通信机制、持久 化机制和消息机制等对应的公共模块，在 架构设计时会设计得比较深入，因为它们 较多地涉及软件的不同部分之间的交互;而 具体的业务功能模块在架构设计中往往设 计程度不深。
架构设计到什么程度
架构设计到什么程度，指导思想为：
成功的架构设计的关键要素
• 1.是否遗漏了至关重要的非功能性需求。 非功能性需求从哪里来？
来自用户。例如性能、易用性。 为用 户而设计，不仅要满足用户要求的功能， 也有达到用户期望的质量。
来自开发人员和维护人员。例如可扩 展性、可重用性、可移植性。一个拙劣的 设计，会使开发和维护变成一场噩梦。
来自客户组织。例如预算限制、上线 时间。
缺失重要架构视图
• “缺失重要架构视图”的一种表现是，认为软件架 构设计完全是用例驱动的，片面强调用例描述的 功能需求。此时，架构设计对非功能需求关注不 够，既没有深入设计软件的运行架构（对性能、 可伸缩性、持续可用性等运行期质量属性很重要 ），也没有深入设计软件的开发架构（对可扩展 性、可重用性、可测试性和可移植性等开发期质 量属性很重要）。软件开发人员会感觉到架构设 计方案离他们很“遥远”，既没有说明程序包的组 织结构，也没有明确架构设计中的关键抽象和所 采用框架的关系，等等。
• * 详细设计针对每个部分的内部进行设计。
架构设计与详细设计
• 软件架构设计应当解决的是全局性的、涉及不 同“局部”之间交互的设计问题，而不同“局部”的 设计由后续的详细设计负责。于是，在软件架 构所提供的“合作契约”的指导之下，众多局部问 题被很好地“按问题广度分而治之”了----对局部 的设计完全可以并行进行。
成功的架构设计的关键要素
• 1.是否遗漏了至关重要的非功能性需求。
非功能性需求分为质量属性和约束两种 ，质量属性是软件系统的整体质量品质， 往往与大多数功能有关，例如易用性、性 能、可伸缩性、持续可用性、鲁棒性、安 全性、可扩展性、可重用性、可移植性、 易理解性、易测试性等。至于约束，要么 是架构设计中必须遵守的原则，例如一些 硬件或者软件的限制，要么转化为质量性 需求或者功能需求。
高来高去式架构设计常见症状
• 症状二：浅尝辄止、不够深入。架构设计 方案过于笼统，基本还停留在概念性架构 的层面，没有提供明确的技术草图。于是 ，全局性的设计决策最后由具体开发人员 从局部视角考虑并确定下来，造成技术和 管理上的种种问题。
高来高去式架构设计常见症状
• 症状三：名不副实的分层架构。通过分层 将架构系统模块之后，就迫不及待地喊出“ 分层架构”的口号，对各层之间交互接口和 交互机制的设计严重不足。
接口和实现分离
分而治之的两种方式
例如：
• “按问题广度分而治之”的例子也很常见，比如 展现层、业务层和数据层的开发往往需要不同 的技术,可以分派给不同的小组承担等,不一而 足。
架构设计与详细设计
• 将设计分为架构设计和详细设计，是对“按问 题深度分而治之”思想的运用。
• * 所谓架构设计，就是关于如何构建软件的一 些最重要的设计决策，这些决策往往是围绕将 系统分为哪些部分，各部分之间如何交互展开 的;
分而治之的两种方式
例如：
• 接口和实现分离，就是“按问题深度分而治之” 的一个例子。在架构设计之时，我们往往无需 深入到一个子系统的实现细节中去，而是分而 治之，先确定该子系统的接口。接口的设计在 整个架构设计中占有重要地位，它定义了一个 子系统为其他子系统所提供服务的契约。软件 架构通过明确每个子系统所要实现的接口及所 要调用的接口，为我们展现了一个软件系统如 何分割为多个相互协作的子系统。
架构设计到什么程度
• 既然软件架构是团队开发的基础，就应该 比较明确地规定后期分头开发所必须的公 共性的设计约定，从而为分头开发提供足 够的指导和限制。
• 另外，具体的架构设计程度还会因软件项 目的不同而不同，例如航空航天领域中的 软件系统对系统可靠性要求非常高，这种 情况下对架构设计详细程度的要求也会比 较高。
高来高去式架构设计带来的危害
* 缺少来自架构的足够的指导和限制，开发 人员在进入分头开发阶段之后会碰到很多问题， 并且容易造成管理混乱，沟通和协作效率低；
* 对软件质量非常关键的全局性设计决定被 拖延到分头开发期间草率决定，严重降低了软件 产品质量；
* 没有完成化解重大技术风险的职责，可能 造成整个项目失败；
架构分析与设计1010
2020年4月28日星期二
主要内容
如何进行成功架构设计 架构设计到什么程度 架构设计过程
何谓成功的软件架构设计
• 所谓成功的架构设计，就是设计出的软件 架构是高质量的，并且在所花费的时间、 技术决策等方面也都满足具体开发情况的 要求；
• 在不适当的时候“用时间换完美”会毁掉整个 项目；