2021-10-27需求分析与系统架构

前言

T31第一天

提示：以下是本篇文章正文内容，下面笔记可供参考

一、T31项目简介

项目介绍
T31项目是类似于12306的售票网站

1、从查票、下单、付钱、通知的主流程
2、抽象商品、订单、支付的核心模型
3、处理票务异常和日志
4、了解架构设计背后的方法论

二、需求分析

理解和挖掘用户的诉求、以及背后的逻辑，转化成可行性的分析结果。从非结构化到结构化，确定系统的职责、模块的规程。
边界：
哪些数据已经有了，哪些模块已经有了。
用户故事：
模拟用户想要做什么，比如候补车票。
用户路径：
我们和系统的触点，就是我们的用户路径，比如我们打开一个APP，点开，输入账号密码。
原则：尽量短。
分析背后的人性：
个人理解是理解这个项目背后的意义，有可能不是单纯为了开发而开发，涉及更多方面的考量，比如KPI，或者打压对手等等。
需求产品化：
模块化、配置化、有逻辑
需求落地路径：
需求分析->可行性->设计->编码->测试->发布

需求反例：

1、伪需求：没有调研、没有目标、没有逻辑的无脑需求
应对：
1、用数据化结果否定需求合理性
2、用正反案例来说明需求需要改进的地方
3、用户路径和触点推演需求合理性

2、权力需求：老板或者是强势业务方的需求
应对：
1、先肯定需求价值再提出需求实现的成本
2、给出更好的需求替代方案
3、从数据和案例角度说明需求快速上线的危害

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

三、架构设计

KISS原则
Keep it simple and smile
simple： 架构的理念是大道至简：解决问题
1、如何让我们的系统有可扩展性和可维护性
2、如何让我们的系统能够恰到好处地解决问题
3、如何让我们的系统能够运行3–5年不重构
smile：
1、业务部门的挑战（价值问题）
2、成本部门的挑战（ROI问题）
3、测试部门的挑战（可测试性）
4、技术部门的挑战（可行性和工期）

DRY原则
Don’t Repeat Yourself

一切重复的代码都可以抽象
重复代码的危害性：
1、不一致性
2、代码冗余
3、容易出BUG

七大设计原则
1.单一职责：

解释： 高内聚、低耦合的延伸
属性和行为向着模块预先定义的功能内聚
模块的名字非常重要

2、里氏代换原则

解释：父类能够出现的地方，子类一定能够出现，这是里氏代换
反之不行

3.接口隔离原则
解释： 接口的粒度尽可能地小同一接口的方法强内聚于同一特征

以本图为例，pay以及refund方法应该在用户侧，agreeRefund应该在管理侧

4、组合复用原则
什么是组合复用原则

组合复用原则也叫合成/聚合复用原则（CARP），就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。
这个原则的简短表述就是：要尽量使用合成/聚合的方式，而不是使用继承。

5、依赖导致原则
细节依赖抽象
底层依赖于高层
例：宪法不依赖于地方法律，而地方法律依赖宪法

6、迪米特原则
迪米特法则（Law of Demeter）又叫作最少知识原则（The Least Knowledge Principle），一个类对于其他类知道的越少越好，就是说一个对象应当对其他对象有尽可能少的了解,只和朋友通信，不和陌生人说话。英文简写为: LOD。

7、开闭原则
(1)一个软件实体如类，模块和函数应该对扩展开放（对于提供方来说），对修改关闭（对于使用方来说）。用抽象构建框架，用实现扩展细节。

(2)当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

(3)编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。

四、架构

1、何为架构
架构是一种能力，而不是一个职位

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

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

3、如何画出架构图
1、搞清楚要画的架构图的类型
2、确认架构图中的关键要素（比如产品、技术、服务）
3、梳理关键要素之间的关联：包含、支撑、同级并列等
4、输出关联关系清晰的架构图

4、 架构图的好与坏
1、布局：图形的上下左右前后6个方向的位置关系
2、颜色：视觉中心在哪里，哪些元素被忽略
3、逻辑：组件之间的依赖，业务实现的可行性

5、架构图的分类
1、业务架构：使用一套方法论，对所涉及到的业务单元进行边界划分熟悉业务
例：团购网站系统 -> 商品类目，订单服务，支付，退款等功能进行清晰划分
2、应用架构：对整个系统的实现进行可视化落地实践，系统的层次 / 开发原则 / 各个层次的应用服务，一般为垂直依赖型。
例：团购网站系统 -> 数据层，服务层，通讯层，展现层

3、数据架构：是一套对存储数据的框架逻辑，根据各个系统应用场景、不同时间段的应用场景，对数据进行诸如数据异构、读写分离、缓存使用、分布式数据策略等划分

4、技术架构：承接应用架构的技术需要，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚

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

7、 UML
定义
Unified Model Language
Unified：说明以前不统一
Model：建模往往需要抽象
Language：交流，为什么能交流，定义共同的协议
分类
统一建模语言，使用图形和符号描述软件模型中的各个元素和它们之间的关系
UML的分类：
静态结构图：
类图、对象图、包图、组件图、部署图
动态行为图：
交互图（时序图与协作图）、状态图、活动图
类的六大关系
1、泛化关系：即继承关系
2、实现关系：实现接口
3、聚合关系：业务上整体与部分可以分开，是关联关系的特例
4、组合关系：业务上整体与部分不可分分开，同样是关联关系的特例
5、依赖关系：只要在类中用到了对方，就存在依赖关系
6、关联关系：体现的是业务逻辑的关系，是依赖关系的特例，具有导航性和多重性

8、类图
类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。
T31核心模型 ：票
核心服务：订单

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

1、关注正常流程
2、不关注逆流程
3、不关注异常流程
4、不关注分支判断

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

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