DDD 领域驱动设计－如何控制业务流程？

需要注意的是，业务流程并不是工作流程，在领域模型中，业务流程的控制很重要，在上篇的领域模型中我们就忽略了这一点，所以在后面的实现中，出现了一些严重的问题，主要是管理员审核 JS 权限申请的业务流程。

先看一下 JsPermissionApply 实体中的 Pass 操作代码：

对应的单元测试代码：

有没有发现一些问题？开通 JS 权限和消息通知，发生在 JsPermissionApply 实体对象持久化之前，这本身的设计就有问题，另外，如果 JsPermissionApply 实体对象持久化失败的话，开通 JS 权限和消息通知会正常执行，相反，开通 JS 权限和消息通知如果出现问题，JsPermissionApply 实体对象持久化也会不受影响，还有就是开通 JS 权限和消息通知放在一起也会有问题。

造成上面这些问题的原因，就是我们之前画的业务流程图太敷衍了，没有具体的进行细化设计，针对管理员审核 JS 权限申请的业务流程，我们再详细的画一下：

可以看到，管理员审核通过 JS 权限申请，JS 权限申请的状态改为“通过”，再开通 JS 权限，然后持久化 JS 权限申请，最后再消息通知用户，整个 JS 权限申请通过的业务流程顺序应该是这样的，对照上面这张图，再看之前的实现，确实牛头不对马尾。

简单总结下审核通过 JS 权限申请的业务流程顺序：

JS 权限申请状态改为“通过”。

开通 JS 权限。

消息通知用户。

好，来看一下改进后的 JsPermissionApply 实体代码：

<code>Passed, Denied, Locked</code> 都是过去式，表示 <code>Pass, Deny, Lock</code> 操作完成之后的行为，可以看到，在这些操作的内容都有 Status 状态的判断，验证的是什么状态下的 JsPermissionApply 才能执行此行为，任何不符合状态的执行都是不合法的，比如执行 Pass 的前提条件是 Status 状态为 Wait，表示只有 Status 状态为 Wait 的时候，才能执行 Pass 并修改其状态，执行 Passed 的前提前提条件是 Status 状态为 Passed，意思就像其命名 Passed 一样，无需多说。

上面最重要的是开通 JS 权限的执行，因为这是 JS 权限申请最终的执行结果，所以我们后面的操作，都必须建立在其成功的基础之上，那有人会有疑问：为什么上面的业务流程顺序不是这样的呢？当申请状态改为“通过”之后，我们才能去开通 JS 权限，这是开通 JS 权限的前提条件，这时候 JS 权限申请状态是没有被持久化的，所以，如果开通 JS 权限失败，JS 权限申请状态是不会被保存的，另外，开通 JS 权限的领域事件并没有返回值，领域事件一般没有返回值的设计，它只是去通知事件订阅者执行，并不一定需要事件订阅者返回结果给它，那我们如果判断开通 JS 权限是否执行正确呢？就是通过异常判断，如果开通 JS 权限的领域事件发生异常，后面的操作也将不会正常执行。

改进后的 JsPermissionApplyTest 单元测试代码：

从上面代码，我们可以清晰看到业务流程的执行顺序，<code>Assert.NotNull</code> 和 <code>Assert.True</code> 就相当于应用层中的 <code>if</code> 判断，如果正确，则继续向下执行。

JsPermissionApply 领域模型经过三篇博文的完善，基本上符合要求了。

在解决方案中，我们可以看到只有领域层、基础设施层和领域层单元测试的项目，并没有应用层和表现层的实现，但到目前为止，我们似乎把整个系统都完成了一样，这种感觉是很美妙的，JsPermissionApply 领域模型在我手心中，任你是 Web 实现或者 WebApi 实现，又或者是其他技术框架，我都不怕，一切都是自然而然的工作，所以，关于后面的实现，你也可以交给其他人去完成，地基由我奠基，盖楼你来完成。

尽管这个系统很简单，但 DDD 确实是一种很美妙的艺术。

本文转自田园里的蟋蟀博客园博客，原文链接：http://www.cnblogs.com/xishuai/p/how-to-control-the-business-processes.html，如需转载请自行联系原作者