百川纯配B2C订单系统设计分析与实践-京东云开发者社区

### 1 背景
目前京东物流纯配订单有多个对接入口，外单及ECLP都直接与各个端交互，定位混乱，导致各个端之间的逻辑调整相互影响制约，不满足业务独立发展诉求；再经过需求迭代演变，存在不少冗余逻辑代码，维护成本增高；订单分属于多套系统，外单及ECLP各有一套数据库，业务语义不统一，不利于数据化建设。百川项目正是基于此建立，以订单中心为统一的入口，将外单及ECLP耦合各个端的业务逻辑提取出来打造成标准能力，向上对接各个端，如开放入口（物流云、物流网关、JOS）、商家工作台、商家快递小程序；向下与各个OFC进行交互；从而更好的满足业务独立发展需求，降低维护成本，提高系统扩展能力，有利于业务快速接入。

### 2 业务概述
#### 2.1 业务架构
百川业务架构对原有业务架构进行了解耦及收口；以订单中心为统一入口，实现交易与生产解耦，各业务条线解耦，标准业务与非标准业务解耦。

![](//img1.jcloudcs.com/developer.jdcloud.com/d2900722-8fe6-4114-8d59-720b5dbf678320220215144924.png)

#### 2.2 需求说明
百川纯配B2C目前涉及到的接入端有：开放入口（物流云、物流网关、JOS）、商家端、商家快递小程序。开放入口请求入参统一由适配层转换为订单中心标准接口入参再对接订单中心，商家端和商家快递小程序不需要适配，由端上直接对接订单中心；订单中心再与快递OFC进行交互。

纯配B2C订单系统需要承接的业务功能有：接单、改址、逆向、弃货、修改、取消、拦截、删除、恢复、询价、状态回传、查询。

纯配快递B2C涉及产品有：特惠送、特快送、生鲜特快、生鲜特惠、特快包裹、特惠包裹、特惠小件、微小件、特瞬送城际、函速达。

### 3 架构设计
#### 3.1 应用系统分析及纯配B2C订单系统外显功能设计
##### 3.1.1 上下游应用系统分析

开放入口（物流云、物流网关、JOS）通过适配层对接订单中心，商家端和商家快递小程序直接对接订单中心；各个入口操作请求都统一由订单中心路由层分发到订单中心标准接口及领域服务进行处理，处理完成后再统一由订单中心分发层下发给各个OFC完成后续流程处理。

适配层、商家端、商家快递小程序、OFC各个端需要获取订单中心数据进行展示或者业务逻辑处理；各个端查询请求都统一由订单中心路由层分发到订单中心数据层进行处理，处理完统一返回查询结果。

![](//img1.jcloudcs.com/developer.jdcloud.com/771c1892-aa2a-49cc-90ec-8b6acd64527f20220215144959.png)

##### 3.1.2 纯配B2C订单系统外显功能设计
根据具体业务需求，为纯配B2C业务设计业务身份(cn_jdl_b2c)，唯一识别纯配B2C业务；按照实际的业务诉求将纯配B2C的业务类型划分为正向（express），逆向（reverse_express），改址（readdress_express），弃货（discard_express）；其中各个业务类型涉及业务场景如下：

- 正向：接单、修改、取消、拦截、删除、恢复、回传、询价；
- 逆向：逆向生成新单、回传；
- 改址：改址生成新单、修改、回传、删除；
- 弃货：弃货生成新单、回传、删除；

#### 3.2 订单中心架构设计

##### 3.2.1命令和查询职责分离

订单中心架构采用CQRS模式进行设计，CQRS（Command Query Responsibility Segregation 命令查询职责分离）是将command和query分离的一种模式。CQRS模式将订单系统操作分为两类，一类是对会引起订单信息发生变化操作的总称，如接单、修改、取消、拦截、删除、恢复等，这类操作统称为command（命令）；另一类是不会对订单信息产生影响的操作总称，如详情查询、复合查询等，这类数据读取统称为query（查询）。

![](//img1.jcloudcs.com/developer.jdcloud.com/14c91ae4-8ad8-490d-9fc1-7e5a6c66cfe320220215145042.png)

运用CQRS模式的核心思想，将订单信息的两种不同类型操作进行分离，command操作涉及比较多的业务规则及逻辑处理，是领域模型的核心；而query不涉及订单信息修改，也不涉及业务逻辑处理，所以不经过领域模型，由数据层统一提供查询接口。

![](//img1.jcloudcs.com/developer.jdcloud.com/9c348cba-5458-40e8-a496-eb734ee76fda20220215145058.png)

订单中心整体架构主要由分发层、业务处理层、下发层三部分组成。

- 分发层及下发层不做业务逻辑处理，也不操作或查询数据；分发层根据业务身份将请求转发给具体的业务线接口进行处理（如B2C、C2C）；下发层根据履行单元（如JDL.ORDER.B2C、JDL.ORDER.C2C）将处理请求下发给具体的OFC（如快递OFC、快运OFC）。
- 业务逻辑层主要分为业务层及数据层；业务层基于领域驱动设计实现核心业务功能，并调业务层数据操作接口完成数据存储；数据层主要提供数据操作及数据查询相关接口。

##### 3.2.2 洋葱圈架构思想

在架构思想上，主张像洋葱圈架构那样，以领域为核心；洋葱圈架构与六边形架构有着相同的思路，它们都通过编写适配器代码将应用核心从对基础设施的关注中解放出来，避免基础设施代码渗透到应用核心之中。这样应用使用的工具和传达机制都可以轻松地替换，可以一定程度地避免技术、工具锁定。

与六边形架构不同的是洋葱架构存在着不止两个层次，它在业务逻辑中加入了一些领域驱动设计的过程中被识别出来的层次（Application，Domain Service，Domain model，Infrastructure等）；在洋葱架构中，明确了依赖的方向，外层依赖内层，内层对外层无感知。

![](//img1.jcloudcs.com/developer.jdcloud.com/2192679c-2097-4853-a0ef-e81f284187a720220215145141.png)

基于洋葱架构思想，订单中心对外定义标准接口，以纯配订单领域为核心，引入Batrix框架，实现领域服务中对标准能力的流程编排，完成具体业务场景主流程逻辑处理及响应。

![](//img1.jcloudcs.com/developer.jdcloud.com/e633185c-1c72-4b1f-bddc-77a9a8214d0720220215145151.png)

##### 3.2.3 分层设计

###### 1）业务逻辑层分层设计
主要是将业务逻辑层拆分为应用层、领域层、基础设施层。

![](//img1.jcloudcs.com/developer.jdcloud.com/c9fa5b89-9f8e-4043-b980-9603d614d46720220215145221.png)

###### 2）业务逻辑层模块功能设计

业务逻辑层主要由三大模块组成：

- 第一个模块是核心领域服务，主要通过Batrix框架对标准能力进行流程编排完成主流程业务逻辑处理；
- 第二个模块是异步任务，主要职责是异步重试及失败重试（如下发失败重试、持久化失败重试、资源预占 释放、退款等）；
- 第三个模块是消息处理，主要是监听外部系统变更消息，调用相关服务完成数据更新。

![](//img1.jcloudcs.com/developer.jdcloud.com/fe981d2c-78f6-4e6d-8faa-3a44c9c4309620220215145248.png)

#### 3.3 订单中心标准接口及核心领域服务设计
##### 3.3.1 标准接口设计
标准接口设计遵循业界主流的规范化模型结构，即对现实世界客观存在的事物建立领域模型，围绕指定的领域模型引入待构建的系统，为该系统构建设计模型，用代码实现具体的设计模型，完成交付。

![](//img1.jcloudcs.com/developer.jdcloud.com/db612c84-b6fc-49e1-9638-889860ac8fe820220215145310.png)

围绕纯配交易订单域构建设计模型，即边界模型和内部模型的构建；边界模型主要是理清和确认百川纯配B2C订单系统需要具备的能力，即标准接口的定义；内部模型主要是对边界模型的进一步细化，即对标准接口的实现。

![](//img1.jcloudcs.com/developer.jdcloud.com/88b53bad-791e-481e-93af-395f2148fc0020220215145326.png)

##### 3.3.2 核心领域服务设计

###### 1）纯配订单限界上下文设计

纯配订单上下文主要以订单域为中心，其他非订单域信息主要用于记录各个流程处理结果，便于后续流程节点使用以及作为服务执行结果返回。

![](//img1.jcloudcs.com/developer.jdcloud.com/3722902a-5291-411b-ae3d-ec1fcd09f5da20220215145352.png)

###### 2）领域服务设计
核心领域服务的目标主要是在满足业务功能需求的同时具备一定的质量属性（可用、可修改、安全、性能、扩展性）；因此将通用业务逻辑抽象成标准能力（如基本信息校验、客户配置信息校验、敏感信息校验、产品信息校验、地址解析、预分拣校验等），在具体场景（如接单、修改、取消、回传、删除等）下，将所涉及到的标准能力进行流程编排，实现具体场景服务的业务功能需求。

###### 3）订单中心标准能力设计

订单中心标准能力是主要由通用能力层、扩展插槽及扩展插槽实现、防腐层、外部服务接口定义及实现组成；

- 通用能力层（FlowNode）主要是对某一场景（如接单、修改、取消等）下通用的业务逻辑处理进行抽象实现，如基本信息校验中，订单域要求必填的字段信息校验；
- 扩展插槽及扩展插槽实现主要是对个性化需求的定义及实现，如基本信息校验中，不同业务线对不同字段信息是否为空要求不同，需要放到各条业务线的扩展能力中处理；
- 防腐层主要是将订单相关信息映射到外部系统的请求域信息，这样使订单领域服务不受外部系统的改动影响；
- 外部服务接口定义及实现主要是规范外部系统服务接口命名，使之符合订单领域服务命名规范，并调用外部服务，完成相应业务逻辑处理并返回结果，如果有异常则统一抛出订单领域服务定义的异常类。

![](//img1.jcloudcs.com/developer.jdcloud.com/89816796-69cc-43f1-8b17-30530a2ebda820220215145440.png)

##### 3.3.3 扩展能力设计
订单中心涉及多条业务线，如C2C、B2C、O2O、快运等；某条业务线个性化的业务逻辑，对另外的业务线是可共用的，但不是所有条线都可共用，为了减少系统业务逻辑功能的冗余，将扩展功能模块拆分为水平扩展模块和垂直扩展模块；水平扩展模块是对两条及两条以上的但不是所有业务线可共用的扩展功能的实现，垂直扩展模块是对单条业务线个性化扩展功能的实现。

### 4 项目结构设计
#### 4.1 项目结构

jdl-oms-express-client模块是对外标准接口定义；
jdl-oms-express-application 标准接口实现，调用领域服务实现对外能力输出；
jdl-oms-express-domain 订单中心领域服务、领域流程、扩展点规范定义及标准能力实现；
jdl-oms-express-horizontal 订单中心水平扩展通用能力实现；
jdl-oms-express-share-common 通用数据字典常量定义；
jdl-oms-express-test 纯配能力单元测试项目功能块;
jdl-oms-express-vertical-xxx 订单中心各业务条线(如c2c、b2c、o2c等)垂直能力实现;
jdl-oms-express-web 项目配置容器，其中jdl-oms-express-mian模块启动对外提供服务能力，jdl-oms-express-worker模块启动执行异步任务和消费外部系统消息。

![](//img1.jcloudcs.com/developer.jdcloud.com/47a5e629-4f8f-4d16-8442-e4ab0b1b883820220215145635.png)

#### 4.2 模块依赖关系

![](//img1.jcloudcs.com/developer.jdcloud.com/f7c21b19-5239-4286-ae9b-80bfd68e14d520220215145659.png)

### 5 总结

纯配订单中心整体架构设计采用了DDD（领域驱动设计）的思想，并运用CQRS模式将系统划分为领域服务层和数据层，从而实现了订单域业务逻辑处理及订单信息查询的分离，提高了系统的健壮性，有利于系统的持续扩展。

订单中心整体架构采用了洋葱圈架构思想进行设计，有利于项目中使用的工具和传达机制都可以轻松地替换；同时业务逻辑层分层清晰，有利于分离业务逻辑和技术细节，提高了系统的可修改性。

订单系统标准接口及领域服务设计遵循业界主流的规范化模型结构，围绕纯配交易订单域构建设计模型（边界模型、内部模型）、代码模型，有利于减少代码实现和架构之间的差异，使系统在满足业务功能需求的同时具备一定的质量属性（可用性、可修改性、安全性、性能）

------------

###### 自猿其说Tech-京东物流技术发展部
###### 作者：李勇