DDD 实战 (9)：冲刺 1 战术之服务设计
4. 首个冲刺的服务设计
本篇完成 sprint1 的服务设计的主要部分（鉴权上下文、订单上下文）。这里说的“服务”其实是前面第 7 篇中识别出来的“服务功能”。这里服务设计将遵循第 7 篇中已经列出的服务契约来进行。
4.1 服务设计的步骤和方法
顾名思义，“服务设计”其实就是针对前面梳理出来服务契约表中各个“服务功能”内部逻辑的实现。之所以要完成这部分设计，是为了将“服务功能”内部的逻辑落实到聚合（含实体和值对象）、领域服务等 DDD 设计要素上去，避免出现“贫血模型”代码（相对应的，我们称符合 DDD 设计的代码为“富领域模型”）。
要达到这个目的，我们可以通过如下的 5 个步骤来完成服务设计：
服务功能梳理。我们需要基于“业务用例规约”描述，采用“动词短语”的方式，将“服务契约表”中的“服务功能”进行职责描述。事实上，这里的“服务功能”就是我们在菱形架构中提到的“应用服务”（“远程服务”只是“应用服务”跨进程的服务包装输出）。为了完成这个工作，我们需要考虑如下 3 个方面：
a) 将“业务用例规约”中“基本流程”与该服务功能相关的逻辑，采用“动词短语”的方式表达出来（先不用考虑该动作由哪个对象完成）；
b) 考虑“业务用例规约”中“替代流程”中与该服务功能相关的逻辑，也采用“动词短语”的方式表达出来（同样先不用考虑该动作由哪个对象完成）；
c) 将前面聚合设计时，动词建模识别的时标对象的处理逻辑，加入到服务功能的“动词短语”描述中；
任务分解。任务分解的目的，是将服务功能这一“应用服务”作为总体“组合任务”来看待，然后将其分解为多个子任务。这些子任务可能还会包含子组合任务、原子任务两种情况，最终分解的粒度是一定要到“原子任务”的粒度。从“业务用例”开始，我们理解的最终分解结构图示如下：
而具体分解规则如下：
a) “原子任务”遵循“单一知识原则”，是可以被一个聚合、或一个端口（含资源库端口、客户端端口、发布者端口等情况）来独立完成的部分；
b) “组合任务”更多是协调多个聚合、或需要协调聚合与端口、或需要单独考虑某些与业务变化趋势不一致的技术性变化而的抽离出来的业务逻辑，这些逻辑一般都是“无状态服务”的协作模式，是一种对聚合和/或端口逻辑的编排。
c) “组合任务”的分解粒度，需要注意的一些细节是：在判断逻辑编排的位置时，如何判断是在“领域服务”中实现，还是“应用服务”实现？有如下主要两个考虑因素：
i. 一般来说，“非此不可、顺序只能如此”的业务逻辑放在“领域服务”中，而“可有可无、顺序可随意调整”的业务逻辑，则放到“应用服务”中。比如：假设“提交订单”时包含 3 步：“创建订单、清空购物车、向商家发送通知”。其中“创建订单、清空购物车”是“非此不可、顺序只能如此”的部分，所以放“领域服务”，而“向商家发送通知”则属于“可有可无、顺序可随意调整”的部分，所以放“应用服务”。简单点总结来说：其实“应用服务”中的逻辑是“可编排”的，而领域服务内的逻辑其实是“不可编排”的。
ii. 领域服务处于“核心领域”层，而应用服务处于“北向网关”层，因此如果涉及到跟对外接口转换相关的处理逻辑（例如：根据输入信息转换为某个实体对象或值对象），应该放到应用服务，而不应该出现在领域服务中。
职责分配。其实就是将“原子服务”分配到具体的聚合或端口去实现、将“子组合服务”分配到“领域服务”去实现。总结起来，职责分配遵循如下的规则：
a) 子组合任务，分配职责到“领域服务”（需要将“应用服务”拆分为多个“领域服务”的逻辑，上面已经说明）；
b) 原子任务，不需要访问数据存储、其它上下文等外部资源，则分配职责到“聚合”（具体可能是聚合中某个实体或值对象类的行为方法）；
c) 原子任务，需要访问数据存储的，分配职责到“资源库端口”；
d) 原子任务，需要访问其它上下文服务的，分配职责到“客户端端口”；
e) 原子任务，需要发布领域事件消息的，分配职责到“发布者端口”；
f) 如果“应用服务”还需要跨进程提供服务（比如：对客户端、对微服务其它进程），则还需要将“应用服务”对外包装成“远程服务”。
“坏味道”识别和改进。在完成“职责分配”后，建议采用序列图的方式来检查是否有设计的“坏味道”，并对发现的“坏味道”进行设计优化。如下图所示：
其中：
a) 五角星表示供客户端角色使用的服务，应该只有一个，如果有多个就应该拆分到多个“应有服务”中去；
b) 三角形一个对象向另一个对象发起的调用，如果一个对象生命线上出现多个，说明该对象要么承担了协调控制角色，要么就是坏味道。而“协调控制角色”大多由“领域服务”或“应用服务”承担，且即便如此它们也不宜承担过多协调控制职责（一般为 3 个以下），“远程服务”、“聚合”、“端口”等则完全不该承担协调控制职责。
c) 菱形表示一个对象承担的职责，也不宜过多。如果过多，某个对象在所有“应用服务”实现序列图中，加起来有超过十多甚至二三十个以上职责，则可能该对象违背了“单一知识原则”，承担了过多的职责需要再进行细粒度职责分解。
这里的对象和方法命名规则建议：
a) 远程服务以服务类型作为类名后缀：控制器类服务后缀为 Resource，资源类服务后缀为 Resource，事件发布者后缀为 Provider，事件订阅者后缀为 Subscriber。
b) 应用服务以 AppService 为类名后缀。
c) 领域服务以 Service 为类名后缀。不过，也可以考虑将体现服务价值的动词名词化，比如叫：OrderPlacingService。这样做的缺点是可能会导致大量碎片化的领域服务。为了减少这种情况，建议在类似 OrderService 这样的领域服务类下的方法过多（比如超过二三十个）时，可以采用这样的命名规则。
d) 应用服务和领域服务的方法名建议以动宾结构的短语为主，要能够描述出服务的业务价值。如：submitOrder()。
e) 资源库端口名称以对应的聚合名称加 Repository 后缀。
f) 客户端端口名称以“宾动结构”加 Client 后缀，如：WxPrepayingClient。
4.2 鉴权上下文服务设计
4.2.1 微信用户登录
服务功能梳理
根据业务用例“登录系统”的用例规约描述，我们知道“微信用户登录”主要完成如下步骤（其它步骤不属于 sprint1 范围，暂不考虑）：
根据微信前端 code，调用微信 auth.code2Session 接口获取微信 openid；
为了确保信息安全，基于微信鉴权信息校验微信用户信息完整性；
根据微信 openid 查找该用户已有的用户记录、或新建用户记录；
为用户创建具备有效期的登录令牌，并返回给微信小程序前端；
同时，根据前面的“动词建模”我们还发现该服务功能应该记录“登录日志”。为此，我们将该服务功能需要完成的逻辑完善后，“动词短语化”如下：
调用微信 auth.code2Session 接口获取 openid；
校验微信用户信息完整性；
找 openid 对应的已有用户记录、或新建用户记录；
生成用户登录令牌；
记录用户登录日志；
任务分解
首先，我们对服务功能进行任务分解。上面的服务功能描述中，关于用户记录、登录日志、登录令牌的动作，都是可以再继续“原子化”分解的。如下：
调用微信后台接口获取登录凭证；
校验微信用户信息完整性；
确保 openid 对应用户记录存在；
根据 openid 查找用户记录；
如果未找到，则：
创建用户记录；
保存用户记录；
生成用户登录令牌；
创建用户登录令牌；
保存用户登录令牌；
记录用户登录日志；
创建用户登录日志；
保存用户登录日志；
其次，我们发现前面两个原子任务其实是可以组合到一个“组合任务”中，就叫“微信后台登录并校验”好了。所以，我们可以把任务分解调整成如下内容：
微信后台登录并校验；
调用微信后台接口获取登录凭证；
校验微信用户信息完整性；
确保 openid 对应用户记录存在；
根据 openid 查找用户记录；
如果未找到，则：
创建用户记录；
保存用户记录；
生成用户登录令牌；
创建用户登录令牌；
保存用户登录令牌；
记录用户登录日志；
创建用户登录日志；
保存用户登录日志；
职责分配
下面我对上节分解后的任务进行职责分配。按照分配原则，结合上一章的“聚合设计”，我们分配如下：
微信后台登录并校验；（组合任务，领域服务）
调用微信后台接口获取登录凭证；（原子任务，client 端口，访问微信开放接口）
校验微信用户信息完整性；（原子任务，瞬态值对象行为，按照微信接口标准要求完成信息校验）
确保 openid 对应用户记录存在；（组合任务，领域服务）
根据 openid 查找用户记录；（原子任务，资源库端口，访问数据库）
如果未找到，则：
创建用户记录；（原子任务，聚合或工厂，创建对象）
保存用户记录；（原子任务，资源库端口，访问数据库）
生成用户登录令牌；（组合任务，领域服务）
创建用户登录令牌；（原子任务，聚合或工厂，创建对象）
保存用户登录令牌；（原子任务，资源库端口，访问数据库）
记录用户登录日志；（组合任务，领域服务）
创建用户登录日志；（原子任务，聚合或工厂，创建对象）
保存用户登录日志；（原子任务，资源库端口，访问数据库）
除了上面的原子任务、组合任务的职责分配外，我们还需要考虑另一个问题：哪些组合任务由领域服务来协调、哪些组合任务由应用服务来协调。根据我们前面的区分原则：“非此不可、顺序只能如此”的业务逻辑放在“领域服务”中编排，否则就放在“应用服务”中编排。我们分析上面的几个组合服务可以看出，下面这些步骤是“非此不可、顺序只能如此”的业务逻辑：
1. 必须先完成“调用微信 auth.code2Session 接口登录微信后台”后，才能进行后面的“确保用户记录存在”，因为后者要用到前者返回的 openid；
2. 必须在“确保用户记录存在”后，才能“记录登录日志”和“生成登录令牌”，因为后两者需要用到用户标识 ID；
3. 从返回给小程序前端（用户角色）的角度来说，“生成登录令牌”是不可或缺的，不能被省略的；
而下面是可能涉及到“可有可无、顺序可随意调整”相关业务逻辑的考量：
1. 从返回给小程序前端（用户角色）的角度来说，“记录登录日志”其实是可有可无的；
2. 从执行的顺序来说，“记录登录日志”是在“生成用户登录令牌”之前还是之后，其实是可以随意安排的；
3. 但从时标对象为了规避法律纠纷风险的角度来说，“记录登录日志”又是不可或缺的；
为此，我们将上面的任务分解职责分配结果调整为如下结果：
微信用户登录；（组合任务，应用服务）
微信登录并获取令牌；（组合任务，领域服务）
微信后台登录并校验；（组合任务，领域服务）
调用微信接口登录微信后台；（原子任务，client 端口，访问微信开放接口）
校验微信用户信息完整性；（原子任务，瞬态值对象行为，按照微信接口标准要求完成信息校验）
确保 openid 对应用户记录存在；（组合任务，领域服务）
根据 openid 查找用户记录；（原子任务，资源库端口，访问数据库）
如果未找到，则：
创建用户记录；（原子任务，聚合或工厂，创建对象）
保存用户记录；（原子任务，资源库端口，访问数据库）
生成用户登录令牌；（组合任务，领域服务）
创建用户登录令牌；（原子任务，聚合或工厂，创建对象）
保存用户登录令牌；（原子任务，资源库端口，访问数据库）
记录用户登录日志；（组合任务，领域服务）
创建用户登录日志；（原子任务，聚合或工厂，创建对象）
保存用户登录日志；（原子任务，资源库端口，访问数据库）
坏味道识别
我们先根据上一节的职责分配后的“动词短语性功能描述”，画出该服务功能的实现序列图如下（需要说明的是：下面的远程服务我们以 Resouce 后缀命名，是以为我们虽然这里开发的是“群买菜”服务端第二版，并为了兼容第一版我们开发了 BFF 边缘层，但我们仍然希望第二版本开发的远程服务是可以作为远程资源服务，支持 RESTful 规范的）：
备注说明如下：
1. 图中用各种颜色标出了“菱形架构”各个角色（不包含“南向适配器”，因为那是依赖注入的）。
2. 五角星表示供客户端使用的服务请求，三角形表示对象发起调用，菱形表示对象承担的职责。
从该序列图中，我们看到：大部分调用发起和职责承担均没有“坏味道”。但有个“创建对象”的地方需要注意：
1. 新登录微信用户，我们现在是让 User 聚合根实体类自带的工厂方法去创建对象。这是有问题的：因为创建这个对象时，需要用到小程序客户端提交的微信用户信息（昵称、头像、性别、地区等），而这些信息我们是通过类似 WxLoginRequest 这样的发布语言类（其实是一种 DTO——纯数据传输对象）传给应用服务的。我们在 User 类的工厂方法中创建实例，就会使得 User 类依赖于 WxLoginRequest 发布语言类，这是不合理的：从代码分层上，出现了“内层依赖外层”的问题，不符合简洁架构原则。为此，我们需要在应用服务层，就要求通过 WxLoginRequest 发布语言类的工厂方法来创建 User 实例，并将该实例传入到领域服务后领域服务判断是将其作为新 User 对象看待。
这里需要说明的是：关于实体对象的创建工厂到底应该怎么实现，有如下几种选择，分别适用于不同的情况：
用得最多的，是聚合自身带工厂方法。这种方案适用于聚合实体对象的创建过程，不需要依赖于其它外在信息（即需要通过南向网关端口去其它上下文获取信息的情况）、且对象基本必填属性的设置比较简单。这种聚合自身的工厂方法在 java 中都是 static 方法，名称往往为 createXxx、instanceOf、of 等。
如果聚合实体对象的非必填属性比较多，且基本必填属性比较简单，且聚合自身就能够决定如何创建对象实例，则可以考虑采用“构建者”设计协作模式。这种协作模式有两种方式：方式 1，聚合提供基本的工厂方法+内嵌的 builder 类（builder 类的各个方法都设置某个聚合属性，并返回 builder 对象实例以便实现“流式接口 fluent interface”）；方式 2，聚合提供基本的工厂方法+一系列设置非必填属性的方法（但这些方法都返回聚合对象本身以便实现“流式接口 fluent interface”)。从简洁性上来说，我个人倾向于第二种方式。
如果聚合实体对象是从客户端调用请求时填入的信息，则可以在“发布语言类”中实现聚合的工厂方法，因为这时候“发布语言类”具备创建聚合对象的最多业务知识。——这种情况，正好是我们这里提到的根据小程序用户信息创建 User 实例的需求。
对于聚合内出现“整体-部分”协作模式的实体对象关系，则可以让代表“整体”的实体对象来实现代表“部分”实体对象的工厂方法。如“订单-订单项”之间，则可以在“订单”类中实现“订单项”的工厂方法。
如果聚合自身不具备足够的信息、且客户端提交请求的信息也不够用来创建实例，还需要组合其它外在信息（即需要通过南向网关端口去获取来自外部存储、其它上下文的信息），则建议引入专门的聚合工厂类、或工厂方法协作模式、或抽象工厂协作模式来实现。
为此，我们将服务序列图调整如下：
根据优化后序列图，最终得出任务分解如下：
微信用户登录；（组合任务，应用服务）
根据客户端请求实例化用户对象；（原子任务，发布语言类工厂，工厂方法）
生成微信登录令牌；（组合任务，领域服务）
微信后台登录并校验；（组合任务，领域服务）
调用微信接口登录微信后台（原子任务，client 端口，访问微信开放接口）
校验微信用户信息完整性；（原子任务，瞬态值对象行为，按照微信加密标准进行校验）
确保用户记录存在；（组合任务，领域服务）
查找用户记录；（原子任务，资源库端口，访问数据库）
如果找到，则：
更新已有用户信息（昵称、头像等）；（原子任务，聚合行为）
更新用户持久化；（原子任务，资源库端口，访问数据库）
如果未找到，则：
设置新用户 openid；（原子任务，聚合行为）
新增用户持久化；（原子任务，资源库端口，访问数据库）
生成用户登录令牌；（组合任务，领域服务）
创建用户登录令牌；（原子任务，聚合行为，创建对象）
更新用户登录令牌（持久化）；（原子任务，资源库端口，访问数据库）
记录用户登录日志；（组合任务，领域服务）
创建用户登录日志；（原子任务，聚合自带工厂，创建对象）
新增用户登录日志持久化；（原子任务，资源库端口，访问数据库）
4.2.2 获取微信绑定手机号
经过 4 步骤设计后的服务功能分解如下：
解密微信手机号；（组合任务，应用服务）
解密微信手机号；（组合任务，领域服务）
从数据库重建用户对象；（原子任务，资源库端口，访问数据库）
获取微信加密手机号；（原子任务，客户端端口，执行微信加密解析）
将微信手机号更新到用户对象；（原子任务，聚合，实体对象行为）
更新用户对象持久化；（原子任务，资源库端口，访问数据库）
该服务功能的序列图如下：
4.3 订单上下文服务设计
4.3.1 保存购物车
经过 4 步骤设计后的服务功能分解如下：
存购物车；（组合任务，应用服务）
根据发布语言类创建购物车；（原子任务，发布语言类工厂方法）
保存购物车；（组合任务，领域服务）
结算购物车商品；（原子任务，客户端端口，访问商品上下文服务）
更新购物车持久化；（原子任务，资源库端口，访问数据库）
该服务功能的序列图如下：
4.3.2 查询购物车
经过 4 步骤设计后的服务功能分解如下（以下的所有服务功能就只给出结果，不再展示中间分析过程）：
查询购物车；（组合任务，应用服务）
查询购物车；（组合服务，领域服务）
从数据库重建购物车；（原子任务，资源库端口，访问数据库）
结算购物车商品；（原子任务，客户端端口，访问商品上下文服务）
该服务功能的序列图如下：
4.3.3 创建付款订单
经过 4 步骤设计后的服务功能分解如下：
创建付款订单；（组合任务，应用服务）
新建订单对象；（原子任务，发布语言类，工厂方法）
提交新订单；（组合任务，领域服务）
结算订单商品（含生成快照）；（原子任务，客户端端口，访问商品上下文服务）
生成订单支付；（原子任务，聚合，实体对象行为）
生成订单操作日志；（原子任务，聚合，实体对象行为）
新订单持久化；（原子任务，资源库端口，访问数据库）
该服务功能的序列图如下：
这里需要说明的是：
其实，这里“结算订单商品”和前面保存/查询购物车时“结算购物车商品”时，其 client 端口调用的“商品上下文”的服务功能，都是“商品上下文”的服务功能“计算多商品结算信息”提供的。
4.3.4 创建订单预支付
经过 4 步骤设计后的服务功能分解如下：
发起订单预支付；（组合任务，应用服务）
发起订单预支付；（组合任务，领域服务）
从数据库重建订单对象；（原子任务，资源库端口，访问数据库）
发起订单预支付；（原子任务，客户端端口，访问微信支付接口）
该服务功能的序列图如下：
4.3.5 查询订单详情
经过 4 步骤设计后的服务功能分解如下：
查询订单详情；（组合任务，应用服务）
查询订单详情；（组合任务，领域服务）
从数据库重建订单对象；（原子任务，资源库端口，访问数据库）
该服务功能的序列图如下：
4.3.6 生效订单
经过 4 步骤设计后的服务功能分解如下：
处理微信支付通知；（组合任务，应用服务）
解包微信接口请求参数，获取微信支付结果；（原子任务，发布语言类，工厂方法）
生效订单；（组合任务，领域服务）
根据订单外部编号重建订单对象；（原子任务，资源库端口，访问数据库）
设置订单状态为“已付款”；（原子任务，聚合，实体对象行为）
更新订单对象持久化；（原子任务，资源库端口，访问数据库）
发布“订单已付款”领域事件；（原子任务，发布者端口，发布领域事件）
需要说明的是：上面的逻辑省略了创建品牌子订单等跟品牌加盟相关的内容，因为那是后面冲刺的内容，故不包含。
该服务功能的序列图如下：
4.3.7 查询订单列表（CQRS）
正如前面战略设计技术决策中所说，这个查询列表的服务放在“业务查询中心”微服务中，采用 CQRS 查询代码模型，不采用领域代码模型，故不做 DDD 战术服务设计。
4.3.8 查询订单列表（CQRS）
同上，这个服务功能不采用领域代码模型，采用 CQRS 查询代码模型，故不做 DDD 战术服务设计。
4.3.9 确认订单完成
经过 4 步骤设计后的服务功能分解如下：
确认订单完成；（组合任务，应用服务）
关闭订单；（组合任务，领域服务）
从数据库重建订单对象；（原子任务，资源库端口，访问数据库）
设置订单状态为“已关闭”；（原子任务，聚合，实体对象行为）
更新订单对象持久化；（原子任务，资源库端口，访问数据库）
发布“订单已关闭”领域事件；（原子任务，发布者端口，发布领域事件）
该服务功能的序列图如下：
4.3.10 自动确认超时订单
经过 4 步骤设计后的服务功能分解如下：
自动确认超时订单；（组合任务，应用服务）
取出所有超时未确认的订单列表；（组合任务，领域服务）
从数据库获取“订单确认超时参数”；（原子任务，资源库端口，访问数据库）
查询所有满足超时未确认的订单；（原子任务，资源库端口，访问数据库）
对每个订单循环：（组合任务，应用服务）
关闭订单；（组合任务，领域服务）
设置订单状态为“已关闭”；（原子任务，聚合，实体对象行为）
更新订单对象持久化；（原子任务，资源库端口，访问数据库）
发布“订单已关闭”领域事件；（原子任务，发布者端口，发布领域事件）
该服务功能的序列图如下：
4.3.11 删除订单
经过 4 步骤设计后的服务功能分解如下：
删除订单；（组合任务，应用服务）
删除订单；（组合任务，领域服务）
从数据库重建订单对象；（原子任务，资源库端口，访问数据库）
设置订单为不可见状态；（原子任务，聚合，实体对象行为）
更新订单对象持久化；（原子任务，资源库端口，访问数据库）
该服务功能的序列图如下：
4.3.12 自动取消超时订单
经过 4 步骤设计后的服务功能分解如下：
自动取消超时订单；（组合任务，应用服务）
取出所有超时未支付的订单列表；（组合任务，领域服务）
从数据库获取“订单支付超时参数”；（原子任务，资源库端口，访问数据库）
查询所有满足超时未支付的订单；（原子任务，资源库端口，访问数据库）
对每个订单循环：（组合任务，应用服务）
取消订单；（组合任务，领域服务）
设置订单状态为“已取消”；（原子任务，聚合，实体对象行为）
更新订单对象持久化；（原子任务，资源库端口，访问数据库）
该服务功能的序列图如下：
到此，我就完成了 sprint1 服务设计的主要工作——包含鉴权上下文 2 个、订单上下文 12 个共计 14 个服务功能的“服务设计”工作，还剩下 7 个（商品上下文 5 个、店铺上下文 1 个、平台集成上下文 1 个）。我将在下篇中完成它们，并包含战术设计的相关技术决策（这种技术决策只有第一次冲刺才有），进而完成 sprint1 的全部战术设计。
版权声明: 本文为 InfoQ 作者【深清秋】的原创文章。
原文链接:【http://xie.infoq.cn/article/8839a8d648a4bad6a8880318f】。文章转载请联系作者。
从菜鸟向大神攀登。。。 2020.11.15 加入
21年IT从业经验，热爱写代码、软件架构设计、软件产品设计。最近决定把自己的一些代码或设计经验分享出来，希望对大家有用！个人秉承职业理念：自己给自己加班，提升自己的稀缺性，其实所有人都可以突破年龄障碍！
评论