对TJ项目的学习全流程day02
学习点:
1.拿到业务后对业务的全流程分析
2.分析接口
3.分析接口参数
4.设计领域模型
文章目录
前言
对于拿到业务后的全流程的总结
一、分析业务的技术使用可能
是否运用中间件,组件·选型等等。
二、接口分析
1.分析UI设计稿
拿到UI设计稿,分析接口及参数
2.分析项目业务的接口需求
画出整体业务流程图
基于流程图画出项目时序图(时序图(Sequence Diagram):又名序列图、循序图,是一种UML交互图。它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作)
所有图结束后,确定需要的接口
编号 | 接口描述 | 请求方式 |
---|---|---|
1 | 支付或报名课程后,立刻加入课表 | MQ通知 |
2 | 分页查询我的课表 | GET |
3 | 查询我最近正在学习的课程 | GET |
4 | 根据id查询指定课程的学习状态 | GET |
5 | 删除课表中的某课程 | DELETE |
6 | 退款后,立刻移除课表中的课程 | MQ通知 |
7 | 校验指定课程是否是课表中的有效课程(Feign接口,已定义但未实现) | GET |
8 | 统计课程学习人数(Feign接口,已定义但未实现) | GET |
三,分析项目的核心领域模型
将数据库的表,各个表的相关的关联联系进行分析和模型设计,
数据库设计一般我们会遵循三范式去实践落地
三范式设计原则
第一范式:表中字段的数据,不可以再拆分
第二范式:表中任意一个主键或任意一组联合主键,可以确定除该主键外的所有的非主键值
第三范式:在任一主键都可以确定所有非主键字段值的情况下,不能存在某非主键字段 A 可以获取 某非主键字段 B
设计案例:用户课程表
参数名 | 描述 | 是否需要 |
---|---|---|
id | 课表id | 需要 |
courseId | 课程id,用户点击创建计划、删除课程使用 | 需要 |
courseName | 课程名称 | 不需要,违背三范式,应该课程id去查询获得 |
courseCoverUrl | 课程封面,首页展示课程有,这里没有 | 不需要,违背三范式,应该课程id去查询获得 |
sections | 课程总课时数 | 不需要,违背三范式,应该课程id去查询获得 |
status | 课程学习状态(未学习、已学习、已学完、已失效) | 需要 |
learnedSections | 已学习课程数 | 是学习进度的某一个字段,所以应该改成存储最近一次学习的小节id |
planStatus | 学习计划状态(决定是否展示:创建学习计划) | 需要 |
createTime | 有效学习周期的开始时间,即加入课表时间 | 需要 |
expireTime | 有效学习周期的结束时间,即过期时间 | 需要 |
在此基础之上,课程应该是某个用户的,所以还应该有用户id:user_id
四.确定接口的详细出入参
确定接口出入参+协议,在做接口设计时需要想好接口的封装、聚合、开闭原则等。
示例:
请求协议
- MQ
接口地址
- 无,参考MQ的3大元素定义即可(Exchange、RoutingKey、Queue)
接口入参
参数名 | 类型 | 描述 |
---|---|---|
orderId | Long | 订单id |
userId | Long | 用户id |
courseIds | List | 订单包含的课程id,可以批量下订单 |
finishTime | LocalDateTime | 支付完成时间 |
接口出参
- 无,MQ发消息成功即可,是无需响应的
接口说明
- 一个订单可能有多个课程,因此需要批量处理
- MQ消费存在失败重试,要确保幂等性,避免重复添加课程
总结
例如:以上就是day02总结的内容,关于拿到项目和业务后如何去分析,对全流程的开发过程。