T31项目简介和需求分析
T31项目简介
- T31是类似于12306的售票网站
- 从查票、下单、付款、通知的主流程
- 抽象商品、订单、支付的核心模型
- 处理票务异常和日志
- 了解架构设计背后的方法论
- 以战促练,全面提升大家的代码能力、设计能力、交付能力和协作能力
需求分析
理解和挖掘用户诉求、以及背后的逻辑,转化成可行性的分析结果.从非结构化到结构化,确定系统的职责、模块的过程.
- 用户通过网站注册并登录
- 车次、车厢、经停站、时刻表增删改查
- 修改个人信息
- 乘客管理
- 余票查询
- 创建(票)订单
- 第三方支付(支付宝)
- 支付成功通知(MOCK)
关于七大设计原则
搜索了一下关于这七大设计原则
-
单一职责原则
高内聚低耦合的延伸
-
里氏代换原则
父类出现的地方子类一定能够出 现反之不一定
-
接口隔离原则
接口的粒度尽可能的小
-
组合复用原则
继承与组合
继承是一种绑定关系,组合是一种松散的合作关系
-
依赖倒置原则
细节依赖抽象,低层依赖高层
-
迪米特原则
互相了解信息,尽可能的少
你使用了一个接口,你只关注输入和输出,你不需要关注具体代码实现
-
开闭原则
对扩展开放,对修改关闭
关于问题的分层
一个问题从不同视角来看，有不一样的描述和要求，想要成长就要从全局来看需求和问题
- （本源问题）用户问题：我想支付
- （经营视角）业务问题：支付一切可以支付的第三方支付工具
- （体系结构）产品问题：支付需要逆向流程、异常流程、对账模块等
- （架构代码）技术问题：高并发、可用性，实现第三方支付的链路
关于架构&架构图
什么是架构?
-
架构是一种能力,而不是一个职位
-
架构=组成+决策
-
组成=模块结构+模块关系
-
决策=约束+设计原则+演化方向
架构的目的
- 确定系统边界,在技术层面上做与不做
- 确定系统里各模块之间的依赖关系与模块的宏观输入与输出
- 使后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化
- 明确非功能性需求，非功能性需求是指安全性、可用性、可扩展性
关于类的六大关系
这篇文章总结的不错 类和类之间的6种关系 - https://zhuanlan.zhihu.com/p/414215614
-
泛化关系（Generalization）
extends
-
实现关系（Realization）
implements
-
依赖关系（Dependency）
类B作为类A的方法的参数或局部变量存在
-
关联关系（Association）
类B作为成员变量形式存在于A类中
-
聚合关系（Aggregation）
关联关系的一种特例，整体和部分的关系
整体部分可以分离，生命周期不同，has-a的关系
类B作为成员变量形式存在于A类中
-
组合关系（Composition）
关联关系的一种特例，整体和部分的关系
整体部分不可分离，生命周期相同，contains-a的关系 类B作为成员变量形式存在于A类中
