[架构之路-99]：《软件架构设计：程序员向架构师转型必备》-9-确定关键性需求与决定系统架构的因素

Posted 2023-02-16 文火冰糖的硅基工坊

第9章 确定关键性需求与决定系统架构的因素

9.1 概念架构是什么

9.1.1 概念架构是直指目标的设计思想、重大选择

9.1.2 案例1：汽车电子AUTOSAR——跨平台复用

NA

9.1.3 案例2：腾讯QQvideo架构——高性能

NA

9.1.4 案例3：微软MFC架构——简化开发

NA

9.2 概念架构设计概述

9.2.1 “关键需求”进，“概念架构”出

9.2.2 概念架构≠理想化架构

9.2.3 概念架构≠细化架构

9.3 左手功能——概念架构设计（上）

9.3.1 什么样的鸿沟，架什么样的桥

9.3.2 鲁棒图“是什么”

9.3.3 鲁棒图“画什么”

• 应用程序层由特定于此应用程序的那些元素组成。 所以这将包含UI，UI的后端处理以及应用程序和业务逻辑层之间的任何绑定。 在完美的世界里，这个层不会包含任何业务领域的逻辑，纯粹的软件编程。

• 业务逻辑层（BLL）包含特定于业务领域的逻辑，与特定的业务领域强相关。 另外，如果要创build一个单独的BLL，该层应该包含其他应用程序可以使用的逻辑以及这个逻辑。 例如，一组Web服务暴露了一个定义良好的API。 这将BLL与您的应用程序分离开来，并使您可以灵活地在将来构build其他应用程序。

• 业务层负责业务决策和涉及客户协议的逻辑。

• 应用程序层是与业务决策无关的原始进程。

9.3.4 鲁棒图“怎么画”

9.4 右手质量——概念架构设计（下）

9.4.1 再谈什么样的鸿沟，架什么样的桥

9.4.2 场景思维

笼统需求 =》 场景描述 =》 概念设计

在上图中：

指标目标：笼统性的质量需求

场景：明确性的路径

设计决策：根据明确的路径，明确设计决策，以满足笼统的质量要求。

备注:

场景思维的本质是把笼统的质量需求，转换“功能性、场景性、明确化、具体化“需求。

在特定的场景中，体现质量需求！！！

9.4.3 场景思维的工具

备注：

把质量需求转换成特定的场景，原本是需求分析师的责任。

但在现实中，很多需求分析师，只给出功能性需求，非功能性需求都是架构师去挖掘的，更谈不上需求分析师把非功能性需求转换成场景了。这个活，就落在了架构师的身上，如果架构师也没有进行转换，就只能靠程序之间的造化了。

备注：

上述的箭头反应了反向的作用力的过程。

而概念设计时，正好是相反的，即：目标需求，如质量属性 =》分解成质量场景 =》设计决策，决定哪些场景是支持的，哪些场景是不支持的。

9.4.4 目标—场景—决策表应用举例

备注：

在某个场景下，可以有很多if....then.....子场景。

9.5 概念架构设计实践要领

9.5.1 要领1：功能需求与质量需求并重

9.5.2 要领2：概念架构设计的1个决定、4个选择

9.5.3 要领3：备选设计

9.6 实际应用（7）——PM Suite贯穿案例之概念架构设计

9.6.1 第1步：通过初步设计，探索架构风格和高层分割

9.6.2 第2步：选择架构风格，划分顶级子系统

9.6.3 第3步：开发技术、集成技术与二次开发技术的选型

9.6.4 第4步：评审3个备选架构，敲定概念架构方案