使用DDD开发电商系统中的订单业务

电商系统中的订单模块属于老生常谈的业务了。基本上一谈到电商系统就会聊一聊订单相关的业务。
这篇文章将使用UML来分析订单业务，使用领域模型实现订单业务。

分析业务

订单流程可以分为：确认订单、提交订单、付款、配送、售后服务五个部分。

确认订单(incomplete)，此时主要是确认订单的数据比如：顾客信息、配送地址、订单商品。
提交订单(pending)此时会对订单数据进行校验以及更新商品库存，比如顾客是否有效，商家是否处于营业，购买的商品库存是否满足等等。
付款，包括等待付款(awaiting payment)和付款完成(paid)两步骤。
在创建订单完成并开始付款时，会将订单标记为等待付款。当付款完成后，会将订单状态标记为等待打包。此时将进入配送阶段。
配送，整个配送阶段由等待打包(awaiting fulfillment)、等待揽收(awaiting shipment)、
已发货(shipped) / 部分发货(partially shipped)、等待收货(awaiting pickup)、确认收货(completed)组成。
其中前四个状态由商家或配送员完成，后两个状态由顾客或配送员完成。
售后服务，对于已收到的商品存在问题(disputed)时，可以申请售后服务。售后服务包括：换货、退货退款、退款。
如果是换货，在换货完成后最终还是回到completed状态。
对于退款来说，退款完成后将产生新的状态分为：部分退款(partially refunded)、退款(refunded)两个状态。

整个订单状态图如下：

接下来我将分别对这五个部分展开讲解。

确认订单

此阶段主要是确认下单的信息，比如选择配送地址、支付方式、配送时间、打印发票、使用优惠券等。

提交订单

此阶段将对确认订单中的数据进行校验，如果校验不合法将返回给客户端重新修改不合法的内容，
并更新订单中商品库存。

大体流程如下图：

我把校验信息的部分做了简化，这个阶段只是为了说明提交订单的主要流程流程。

付款

当订单创建完成响应给客户端以后，客户端将发起支付。
发起支付的瞬间将订单状态更新为待支付，并设置订单的支付超时时间等等。并且还可以与商家协商改价等。

这部分的内容将来交由trade模块详细讲解，此处将不过多讲解。

配送

付款成功后，将由商家来支持配送，商家会通知仓储打包、通知物流公司揽件、发货、收货等等一系列的流程。
这些流程都可以根据上面的有限状态图看到。通常情况下发货都是一次性发出，但有的时候可能出现部分发货的情况。
比如：下单的商品里可能是预订单，此时还没有货可发，所以会先发有货的商品。再比如商品可能需要从多个不同地点的仓库发出等等。

通过上面的分析，我们可以得出订单与快递运单是一个一对多的关系。
可是大家经常看到的订单都是一对一的关系，是的通常情况下会这样。
对于更好的描述大家会对这种一对多的关系根据仓库、商家等等进行自动拆单。但是对于一个模型的分析他最终还是一个一对多的关系。

具体的类图如下：

此类图模型并不完整，他只是描述了今天所用到的知识。

售后服务

对于售后服务中心的退款、退货退款，我将在分析交易模块时再和订单模块整合讲解。此处也不做深入讲解。

总结

整篇文章设计的领域模型有：实体、值对象、领域服务。
其中CustomerValidator与customer模块进行通信用于校验顾客信息是否正确。
CheckoutCounter与inventory模块进行通信用于校验和更新商品库存。
有的时候你会发现有些职责不是实体所拥有的但是还需要实体进行参与其中，
这个时候就是引入领域服务的关键。
就比如实体order身上的customer id，在创建订单时需要校验用户信息是否正确，
如果你直接调用order.validateCustomer()会感到怪怪的。
因为校验用户信息并不是订单对象的职责，所以此时是引入领域服务的关键。