架构

• 业务架构——根据业务需求设计业务模块及其关系
• 系统架构——设计系统和子系统的模块
• 技术架构——决定采用的技术及框架

领域图

领域简图.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. 领域层：
   （1）业务改变才会影响领域层实现，第三方接口和技术实现不影响领域层（通过依赖反转实现）
   （2）只包含领域服务和对象：不应包含与数据库实现绑定、不与第三方接口实现绑定（包含入参出参）
   [[DDD概念]]
2. 防腐层：调用每三方接口后做接口适配（包含接口方法、入参、出参）
3. 命令查询职责分离CQRS：查询接口和新增修改接口分开

（2）事务一致性 TCC

事务一致性实现 - 简书
[[Seate]]
[[rocketmq事务一致性]]

TCC 概念图

tcc.png

下单支付流程

订单TCC.png

（3）状态管理：状态机

订单状态状态机.png 支付状态状态机.png

订单状态：订单子状态（订单主状态、货物状态、交易状态）

其它设计要点

要点一：分清主次
订单状态：订单主状态、子状态（货物状态、交易状态）
主表子表：订单主表、子表
查询接口：精粒度接口（状态查询）、中精度接口（基本信息查询）、细精度接口（外部查询）
消息通知：胖消息（瘦消息+查询）、瘦消息

复杂查询增加查询域：不过违背了（单一职责原则）

要点二：是否拆单？视情况而定

1、京东拆单：京东建设了拆单服务以仓库维度进行拆单
2、拆弹增加了支付的复杂度（需要多单合并支付）

要点三：退款场景支付
红包、优惠券均摊到sku上（使用银行家四舍五入算法拆分）

引用

如何系统地理解「交易平台」？