软件设计过程

将需求转化为设计决策！

本文内容讲解所需的例子为酒店定价系统HPS，其业务驱动因素与系统需求概览如下：

类别	ID/描述	核心内容/目标
业务问题与目标	AD&D酒店业务增长，现有IT系统落后	现代化IT基础设施，替换旧HPS，解决可靠性、性能、可用性、维护性问题，实现系统解耦。
主要功能需求	HPS-1: 登录	用户身份验证与授权访问。
	HPS-2: 更改价格 (高优先级)	授权用户更改价格，系统自动计算并发布。
	HPS-3: 查询价格 (高优先级)	用户或外部系统查询价格。
	HPS-4: 管理酒店	管理员管理酒店基础信息。
	HPS-5: 管理费率	管理员管理费率规则。
	HPS-6: 管理用户	管理员管理用户权限。
关键质量属性	QA-1: 性能 (高)	价格发布 < 100ms。
	QA-2: 可靠性 (高)	100%价格变更成功发布。
	QA-3: 可用性 (高)	定价查询SLA 99.9%。
	QA-4: 可伸缩性 (高)	支持10万至100万次/天价格查询，延迟增加<20%。
	QA-5: 安全性 (高)	凭证验证与功能授权。
	QA-6: 可修改性 (中)	添加新协议查询端点无需修改核心组件。
	QA-7: 可部署性 (中)	应用在非生产环境迁移无需改代码。
	QA-8: 可监控性 (中)	收集100%价格发布性能和可靠性度量。
	QA-9: 可测试性 (中)	系统及元素支持独立集成测试。
系统约束	CON-1: Web浏览器访问	用户通过多平台Web浏览器交互。
	CON-2: 云身份服务与云托管	使用云身份服务管理用户，资源托管在云端。
	CON-3: 专有Git平台	代码托管在公司现有Git平台。
	CON-4: MVP交付时间	2个月内演示MVP，6个月内交付初版。
	CON-5: 初期REST API	初期通过REST API与现有系统交互，后续可能支持其他协议。
	CON-6: 优先云原生方法	设计时优先采用云原生方法。
初始架构关注点	CRN-1: 建立整体初始系统结构	架构设计的首要任务。
	CRN-2: 利用团队现有技术栈	考虑团队对Java, Angular, Kafka的熟悉度。
	CRN-3: 工作分配	考虑开发团队的任务分配。
	CRN-4: 避免引入技术债务	关注系统的长期健康和可维护性。

ADD步骤一：审查输入

在开始设计之前，需要确保设计流程的输入是可用且正确的，这里的正确包括多个考虑点：

• 设计目的
• 主要功能
• 质量属性场景
• 架构约束
• 关注点
• 现有架构设计

示例：酒店定价系统输入

迭代一：建立整体系统结构

ADD步骤二：通过选择驱动因素建立迭代目标

Greenfield系统设计中的第一次迭代目标就是建立一个完整的系统初始结构，那么架构师必须牢记所有可能影响系统整体结构的驱动因素，比如：

• 性能
• 可靠性
• 可用性
• 安全性

在设计早期阶段考虑安全问题尤为重要，因此这个质量属性会得到特别关注

ADD步骤三：选择系统元素进行优化

比如当前这个酒店定价系统项目涉及对现有系统的完全替换，首先需要优化整个系统，这种情况下优化通过分解进行（见属性驱动设计-ADD步骤三）

ADD步骤四：选择满足所选驱动的设计概念

举个例子，还是以这个酒店定价系统为例：

ADD步骤五：初始化架构元素，分配职责并定义接口

示例，还是这个酒店定价系统：

感觉就是在选择具体的技术栈

ADD步骤六：绘制视图并记录设计决策

示例，还是这个酒店定价系统的视图：

决策示例如下：

ADD步骤七：对当前设计进行性能分析，并审查迭代目标及设计目的的实现情况

一般把实现情况分为未解决、部分解决和完全解决

比如还是以这个酒店定价系统为例，本次迭代中做出的决策导致出现新的关注点需要解决：

• CRN-6：选择特定的云技术

则分析情况如下所示：

迭代二：识别支持主要功能的结构

在这个迭代中，开发者需要从迭代一中开发的相对抽象的架构视图过渡到更详细的决定，这些决定将驱动实现

这种转变是ADD方法的内在组成部分，因为我们不能再一开始就设计所有内容，因此我们在做决定时需要小心以确保设计以系统的方式完成。首先解决最大的风险，然后逐步过渡到更精细的细节。

迭代二的目标就是思考实现单元，它会影响到团队的开发。

接下来就是重复ADD步骤二 ~ ADD步骤七，然后完成迭代二后再进行迭代三，相同的步骤…

只不过每个ADD步骤具体要做的事有区别，具体区别看课件Lectue 02 - Attributes Driven Design - Case Study吧，我整理不下去了😅😅😅

😅