DDD领域驱动设计-案例需求文档-Ⅱ

1.背景

为了更全面的说明DDD领域驱动设计相关的知识和技巧，先采用一个案例，通过案例分析，从领域建模，到系统编码，完整的走一遍领域驱动设计流程。

本例所采用的案例为电商业务中的售后补偿系统。基于DDD的模式，实现售后补偿功能的设计和开发。

售后补偿：用户下单收到商品后，发现商品存在如包装，外观，质量等方面的瑕疵，通过补偿申请界面，向电商平台申请补偿的一种业务。常见补偿方案如补发红包，代金卷，金币，退款，重新补发问题商品等。售后补偿简易流程如下：

 

 

特别申明：本文所讲案例为实际某平台的售后补偿系统，基于DDD模式重构后，已经发布上线。采用DDD领域驱动设计，对比历史系统，在系统设计，代码规范性，代码质量，代码理解度方面均有本质的提升。本案例讲解做了脱敏处理，简化部分功能（实际售后补偿业务偏复杂），详情参看以下的需求说明文档。

2.售后补偿需求说明

售后补偿业务简易流程如下：

1. 选择补偿方案，生成售后补偿单；
2. 补偿单审批；
3. 补偿单履约处理；
4. 履约单处理完成，补偿单完结；

补偿申请一共存在三个入口：

1. 客服人员后台发起售后补偿申请；
2. 用户基于app发起售后补偿申请；
3. 线下订单，特殊补偿申请；

三种申请方式入口不同，客户端传入的参数不同，但发起信息均包括以下两部分：

1. 基础信息：补偿单的基础信息；
2. 补偿方案信息：补偿单到底用哪一种补偿方案补偿，如退款，红包。

2.1 补偿基础信息

栏目	说明
基础信息	字段包括：操作人编码，订单号，补偿原因，责任归属（公司原因，供应商原因，物流原因），描述，附件，补偿方式（红包，退款，代金券，补发），补偿属性（商品，非商品），理论补偿金额，实际补偿金额。其他非关键字段。
校验	部分字段的必填验证(订单号，操作人编码，原因编码，补偿方式，责任方归属)； 订单号合规可用（存在，且状态正常）
业务处理	基于订单号，获取订单明细信息。 基于操作人编码，调用用户系统，获取操作人的类型，区别是用户还是后台客服人员。
数据存储	记录补偿单基础信息到相关的数据表。

2.2 补偿方案

补偿方案	栏目	说明
商品退款	基础字段	字段包括：实际补偿值，商品编码，商品数量，商品理论补偿值。
	触发条件	补偿方式不是补发模式； 补偿属性为商品属性；
	校验	商品编码存在订单中； 商品数量大于零，且商品数量<=原始订单中该商品的商品数量； 商品理论补偿值必须大于等于零； 实际补偿值必须大于零；
	业务处理	汇总明细中的商品补偿金额，记录到补偿单基础信息中。补偿单基础信息的理论金额，实际补偿金额为商品明细中合计数据。
	数据存储	记录补偿策略信息到相关数据表中。
非商品 其他补偿	基础字段	字段包括：实际补偿值，理论补偿值。
	触发条件	补偿方式不是补发模式； 补偿属性为非商品属性；
	校验	商品理论补偿值必须大于等于零； 实际补偿值必须大于零；
	数据存储	记录补偿策略信息到相关数据表中。
补发补偿	基础字段	补偿商品编码,发货仓库编码，补偿数量
	触发条件	补偿方式是补发模式；
	校验	补偿商品编码必须存在 补偿数量必须大于零； 发货仓库编码不能为空； 补偿商品在商品系统中存在； 补偿商品的库存大于等于补偿数量；
	业务处理	基于传入的商品编码信息，获取对应的库存信息。 补偿单基础信息的理论金额，实际补偿金额为补发商品明细中合计数据。
	数据存储	记录补偿策略信息到相关数据表中。

2.3 补偿单审批

1. 自动审批：申请人员类型为后台管理人员时，自动审批通过。
2. 手动审批：申请人员类型为电商平台用户时，需相关的管理人员手动审批后，才能继续走流程处理。

2.4 补偿单其他信息完善

1. 补传补偿图片信息：在补偿单处理过程中，系统支持用户重新录入补传图片信息。
2. 填写备注信息：在补偿单处理过程中，支持相关的操作人员填写备注信息。
3. 补偿单终止：在补偿单未发起处理或处理失败时，支持终止补偿单，作废该笔补偿申请信息。
4. 重新发起补偿：补偿履约处理失败后，再次发起处理；

2.5 售后补偿履约处理

1. 补发处理：补偿策略为补发补偿时，重新补发商品，调用订单中心接口，创建一个新的订单。补发处理不能马上获取补发的订单是否已经出库了，需异步等待订单系统回复信息。
2. 商品退款处理：补偿模式为商品原因并退款时，调用退款系统，申请退款。退款是一个异步过程，需等待退款系统回复信息。
3. 商品其他模式退款处理：如红包，代金券等直接调用用户中心接口请求处理，能同步得到系统的处理结果。