抢票系统之架构设计
1.产品需求分析
1.1功能梳理
1.2 需求识别
扩展类需求:不是平台的核心的需求,可能都不是自己实现的,通过本平台进行引流。
功能性需求:真正核心的功能,
非功能性需求:大厂非常重要的一块
1.3业务本质解读
区别于传统的电商系统的一个商品一个SKU,购票的SKU有多种组合,eg:A、B、C、D 四个站就有3+2+1=6种到站组合,3个等级的座位,就会产生18种不同的票面,也就是18SKU。也就是说购票的库存是不可预见的。
核心的业务规则:所有的车票所包含的区间的重叠次数+1,不能超过车次的总座位数,不是说每一个站都要放出所有的票,b-c是大城市可能放的票多
2.核心业务流程分析
2.1 购票且支付
2.2购票未支付
库存和支付有状态流转
2.3 退款
需要处理手续费的处理
2.4 改签
实质是退票+购票
3.DDD方法论
接口层:web浏览器、开放API
服务层:解决方案(购票、改签、退票)
领域层:高内聚、低耦合,不同的领域相互独立
基础层:基础的能力(工具层面)
3.1领域层
4.架构设计
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-B5ybcp03-1648128481424)(/Users/zhaokaijie/Library/Application Support/typora-user-images/image-20220321222050860.png)]
4.2为服务架构
好处:把所有的功能都拆解开了,