订单整理设计
架构
- 业务架构——根据业务需求设计业务模块及其关系
- 系统架构——设计系统和子系统的模块
- 技术架构——决定采用的技术及框架
领域图
领域简图.png
领域明细图.png
针对订单系统领域划分
核心域：下单、支付
通用域：用户管理、支付路由、红包、优惠券
支撑域：履约（运营服务、供应链发货）、售后（开发票、退款、结算、收入）
订单系统设计要点
（1）订单DDD
（2）事务一致性 TCC
（3）状态管理：状态机
（1）订单DDD
由于订单系统属于交易系统的中间枢纽环节，所有业务逻辑会比较复杂，调用方比较多。
DDD工程结构
├── interface ## 用户接口层
│ └── assembler
│ ├── dto
│ ├── facade
├── application ## 应用层
│ └── event
│ │ └── publish
│ │ └── subscribe
│ ├── service
├── domain ## 领域层
│ └── aggregate1
│ │ └── entity
│ │ └── event
│ │ └── repository
│ │ └── service
│ ├── aggregate2
├── infrastructure ## 基础层
│ └── api
│ └── driver
│ └── eventbus
│ └── mq
- 领域层：
（1）业务改变才会影响领域层实现，第三方接口和技术实现不影响领域层（通过依赖反转实现）
（2）只包含领域服务和对象：不应包含与数据库实现绑定、不与第三方接口实现绑定（包含入参出参）
[[DDD概念]] - 防腐层：调用每三方接口后做接口适配（包含接口方法、入参、出参）
- 命令查询职责分离CQRS：查询接口和新增修改接口分开
（2）事务一致性 TCC
事务一致性实现 - 简书
[[Seate]]
[[rocketmq事务一致性]]
TCC 概念图
tcc.png
下单支付流程
订单TCC.png
（3）状态管理：状态机
订单状态状态机.png
支付状态状态机.png
订单状态：订单子状态（订单主状态、货物状态、交易状态）
其它设计要点
要点一：分清主次
订单状态：订单主状态、子状态（货物状态、交易状态）
主表子表：订单主表、子表
查询接口：精粒度接口（状态查询）、中精度接口（基本信息查询）、细精度接口（外部查询）
消息通知：胖消息（瘦消息+查询）、瘦消息
复杂查询增加查询域：不过违背了（单一职责原则）
要点二：是否拆单？视情况而定
1、京东拆单：京东建设了拆单服务以仓库维度进行拆单
2、拆弹增加了支付的复杂度（需要多单合并支付）
要点三：退款场景支付
红包、优惠券均摊到sku上（使用银行家四舍五入算法拆分）
