T31训练营-架构设计

需求分析

理解和挖掘用户的诉求、以及背后的逻辑，转化成可行性的分析结果。从非结构化到结构化，确定系统的职责、模块的过程。

需求分析的内容

注意点：边界、用户故事、用户路径。

1. 边界
   • 明确产品到底做到哪个程度。搞清楚到底要开发什么。确定适用范围，性能要求。确定功能开发成本，正确估时。
   • 职责划分
2. 用户故事
   • 用户要做的任何操作都可以当作一个用户故事
   • 将系统分为成无数个用户故事，要做到每个故事都有价值。
3. 用户路径
   • 用户为了达到某个目的而进行的操作
   • 达到目的的步骤，尽量短，尽可能的简单方便
4. 分析背后的人性： 人性是提出需求的本源
5. 需求产品化：模块化、配置化、有逻辑
6. 需求落地路径：需求分析->可行性->设计->编码->测试->发布

两个分类

面对无脑需求大概有两类：

• 伪需求：没有调研、没有目标、没有逻辑的无脑需求
  什么是: PMF
  应对措施:
  1. 用数据化结果否定需求合理性（市场调研）
  2. 用正反例来说明需求需要改进的地方 （历史经验教训）
  3. 用户路径和缺点推演需求合理性
• 权力需求：老板或者是强势业务方的需求
  应对措施:
  1. 先肯定需求价值再提出需求实现的成本
  2. 用正反例来说明需求需要改进的地方
  3. 用户路径和缺点推演需求合理性

问题的分层

• 本源问题——用户问题:“我想支付”
• 经营视角——业务问题:支持一切可以支付的第三方支付工具
• 体系结构——产品问题:支付需要逆向流程、异常流程、对账模块等
• 架构代码——技术问题:高并发、可用性、实现第三方支付的链路

KISS 原则 Keep it simpe and smile

simpe
架构的理念是大道至简:解决问题

• 如何让我们的系统有可扩展性和可维护性
• 如何让我们的系统能够恰到好处地解决问题
• 如何让我们的系统能够运行 3-5 年不重构

smile
现代软件需要很强的协调能力，保持微笑，迎接各种否定

• 业务部门的挑战——价值问题
• 成本部门的挑战——ROI 问题 （产出比）
• 测试部门的挑战——可测试性
• 技术部门的挑战——可行性和工期

DRY原则 Don’t Repeat yourself

一切重复的代码都可以抽象
重复代码的危害性:

• 不一致性
• 代码冗余
• 易出 Bug

七大设计原则

共同点: 提升软件的可扩展性，可维护性 是抽象思维和归纳思维的集中体现
实践点:

• 类图设计
• 接口设计
• 组合设计

单一职责

• 高内聚、低耦合的延伸，属性和行为向着模块预先定义的功能内聚。
• 名字非常重要，提高可读性

里氏替换原则

• 父类能适用的地方子类必须也能使用，但是子类出现的地方父类不一定能出现。父类
  与子类的关系是一般与特殊的关系，并且子类与父类的基本的本质属性必须一致，这
  样才能保证能替换。

接口隔离原则

• 接口的颗粒度要尽可能的小，接口里的方法强内聚于同一特征，这样的内聚必须根据 实际的业务本质进行划分。

组合复用原则

• 组合是一种松散关系，组合构成的对象方法暴露的少，组合的目的是避免接口污染。
• Autowired注入Service就是组合复用的一种思维

依赖倒置原则

• 细节依赖于抽象，底层依赖于高层
• 统一标准

迪米特原则

• 知识最少原则
• 互相了解的信息少，使用一个接口只需要关注输入和输出，不需要关注该接口的 内部实现。

开闭原则

• 对扩展开发，对修改关闭，该原则是单一职责原则之外最难的。 扩展能力主要是对需求继续变化的适应能力。
• 代码最重要的就是稳定性，一旦成功运行，就不应该该具体的代码扩展。如需更改，应通过依赖倒置，实现增加类，或模块的方式，实现需求的变化。
• 任何变化的点，都是需要被隔离出来的

为什么系统需要面向未来做拓展？

熵增定律
熵:反应自发过程不可逆性的物质状态指标，熵是衡量我们这个世界中事物混乱程度的一个重要指标。 一个孤立系统总是存在从有序度转变成无序的趋势，这就是熵增定律。

开闭原则是熵减
对抗熵增的最好方式就是熵减。熵减最重要的是形成开放性;
开放性设计是系统能够有序接纳外部能量的能力。在软件领域，我们的外部能量指的是需求的多变 和业 务的不断试错。扩展性设计是一种开闭原则思维，比如项目中支付我们未来支付VISA，MASTER，或者 是APPLE PYA。通知未来支持电话语音通知，钉钉等各类办公软件通知等。

架构与架构图

什么是架构

构是一种能力，而不是一个职位

• 架构 = 组成 + 决策
• 组成 = 模块结构 + 模块关系
• 决策 = 约束 + 设计原则 + 演化方向

架构的目的

• 确定系统边界，在技术层面上做与不做
• 确定系统里各模块之间的依赖关系与模块的宏观输入与输出
• 使后续的子系统或模块设计在一个既定的框架内和技术方向熵继续演化
• 明确非功能性需求，非功能性需求是指安全性、可用性、可扩展性等

如何画出架构图

架构图:水平层面的业务模块 + 垂直层面上的技术模块 依赖形成的逻辑结构图

• 搞清楚要画的架构图的类型
• 确认架构图中的关键要素(比如产品、技术、服务)
• 梳理关键要素之间的关联
  - 包含
  - 支撑
  - 同级并列等
• 输出关联关系清晰的架构图

架构图的好与坏

• 布局:图形的上下左右前后6个方向的位置关系
• 颜色:视觉中心在哪里，哪些元素被忽略
• 逻辑:组件之间的依赖，业务实现的可行性

架构图的分类

• 业务架构: 使用一套方法论，对所涉及到的业务单元进行边界划分熟悉业务
  • 购物网站系统 -> 商品类目，订单服务，支付，退款等功能进行清晰划分
• 应用架构: 对整个系统的实现进行可视化落地实践，系统的层次 / 开发原则 / 各个层次的应用服 务，一般为垂直依赖
  • 购物网站系统 -> 数据层，服务层，通讯层，展现层
• 数据架构: 是一套对存储数据的框架逻辑，根据各个系统应用场景、不同时间段的应用场景，对数 据进行诸如数据异构、读写分离、缓存使用、分布式数据策略等划分
• 技术架构: 承接应用架构的技术需要，并根据识别的技术需求，进行技术选型，把各个关键技术和 技术之间的关系描述清楚

传统架构图

• 物理视图:和部署相关的架构决策——一般不画
• 逻辑视图:设计满足功能需求的架构——逻辑结构图
• 开发视图:设计满足开发期质量属性的架构——UML图
• 处理视图:设计满足运行期质量属性的架构——UML图
• 场景视图:需求分析技术，通常采用UML的用例图进行设计

UML

定义：Unified Model Language

• Unified: 说明以前不统一
• Model: 建模往往需要抽象
• Language: 交流，为什么能交流，定义共同的协议

分类

统一建模语言，使用图形和符号描述软件模型中的各个元素 和他们之间的关系

• 静态结构图
  • 类图、对象图、包图、组件图、部署图
• 动态行为图
  • 交互图(时序图与协作图)、状态图、活动图

类的六大关系

• 泛化关系:即继承关系
• 实现关系:实现接口
• 聚合关系 菱形():业务上整体与部分可以分开，是关联关系的特例
• 组合关系 菱形(黑色):业务上整体与部分不可分分开，同样是关联关系的特例
• 依赖关系:只要在类中用到了对方，就存在依赖关系
• 关联关系:体现的是业务逻辑的关系，是依赖关系的特例，具有导航性和多重性

组合强于聚合，架构上要区分组合跟聚合的意义是分解任务时组合不能乱分解。组合解偶代价很高。

类图

类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他 类的关系等。

时序图

通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作

• 关注正常流程
• 不关注逆流程
• 不关注异常流程
• 不关注分支判断

架构图

架构图是什么?

架构图则是表达这种集合的载体，是水平的业务单元 + 垂直的技术单元组成的逻辑结构图

架构图的作用是什么?

将目标系统的结构可视化，通过直观的方式描述技术思维，减少沟通障碍，提升协作效率，划分目标系 统的边界。