DDD-领域工厂的调用时机

背景：

知识星球内探讨领域工厂的调用时机，目前有两种方案：实体调用 or 应用服务调用，我们探讨下两者的优缺点。

show me code (订单创建为例)：

app 层代码：

domain 层代码：

代码 github 老地方：****

关键类：****

代码表达了调用领域工厂的两种时机，我们从几个角度分析一下优缺点。

角度一：领域工厂产生的原因。

我们这个例子的目标是希望创建出一个完整的 OrderEntity，为了达成这个目标，最简单的实现，就是在 OrderEntity 里面新增 insert 的方法，app 层调用一下。

如果 OrderEntity 的创建逻辑非常复杂呢，我们就会把逻辑委托给工厂去做，如图：

这个图表达的就是领域工厂产生的原因，领域工厂产生的原因主要是领域对象的创建过于复杂了，所以我们才新建一个领域元素(工厂)来做这件事情，虽然新增了工厂这个领域元素，但其处于的位置不会发生变化，仍然在 OrderEntity 的创建方法里面，所以从这个角度来看，倾向于第二种实现方式。

角度二：类比法

假如我们现在要对 OrderEntity 进行更新和删除操作，这时候我们会很自然的想到更新和删除是 OrderEntity 的领域能力，领域能力会包含着很多逻辑，那为什么新增不是呢？

所以新增我们认为也是 OrderEntity 的领域能力，工厂创建 OrderEntity 是领域能力的逻辑的一部分，不应该单独暴露给 app 层，如果 app 层想创建 OrderEntity 的话，应该直接去调用 OrderEntity 的新建的领域能力。

有的同学会有另外一种想法，创建是一个操作，挂不到任何一个对象上，所以是领域服务，初想觉得很有道理，但如果按照这种思想，更新删除都是一种操作，那应该都是领域服务，这种想法的本质就是没有识别到领域服务的本质是啥，我们后面会说到领域服务，这里就不展开了。

角度三：模块边界

我们从 app 层和 domain 层的边界来探讨一下，我们认为 app 层的主要职责是对 domain 层的领域能力和领域服务进行编排的，而工厂创建 OrderEntity 这并不是一种领域能力，因为工厂首先并不是业务对象，其次工厂的返回值是内存中的实体，还需要持久化后能力才算完整，这种领域能力的正确的叫法应该是：OrderEntity 创建自己！就如同 OrderEntity 更新自己一样自然，所以从 app 层调用 domain 层的边界来说，app 层也不应该直接和领域工厂打交道。

从三个角度简单分析了一下，我个人更加倾向于方案二哈。

ps：上面的例子是以工厂创建实体为例子来说的，但工厂不是只能创建实体，工厂的职责是为领域对象封装创建逻辑，领域对象即实体和聚合。

加入知识星球即可获得完整文章，加入后，你将获得 4 大特权：

1：DMVP 框架的使用权限(非商用)，DMVP 是一套一小时内可以落地的 DDD 战术框架，只需要在页面上进行模型录入，即可生成标准可用的 DDD 业务框架。

2：视频直播讲解 DMVP，知识星球有问必答(晚上或周末集中作答，好的提问会有代码演示)。

3：多年 DDD 战略战术套路总结，每周一篇，约40篇左右。

4：目前 DMVP 只是 1.0 版本，计划 6 月 15号发布 2.0，7 月底发布3.0，每次版本都是不一样的产品使用姿势和体验，市面上绝没有第二款！

购买内三天内都可以退款的，你可以先买着试试看我们的框架，如果觉得和自己八字不合，欢迎退款，但请不要外泄，谢谢。

目前的DMVP还有很多优化正在进行中，针对每次完善我都会发起投票，听取大家的建议，让我们一起搭建DDD领域的最牛实战框架！

扫描二维码即可获得：