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领域的最牛实战框架！

扫描二维码即可获得：

附上40课课程章节(DMVP框架已经完成，战略设计已完成30%)：

战略设计

0 领域驱动设计学习路径

1 通用语言

· 1.1 通用语言的意义：理解需求的指南针

· 1.2 通用语言的定义和表达

·1.3 快速挖掘通用语言的方法

· 1.3.1 抓住动词，扩展名词

· 1.3.2 思考问题本质的基本方法：WR原则

·1.4 快速转化为领域模型的方法

· 1.4.1 领域模型的图文表示法

· 1.4.2 对号入座法

    · 1.4.2.1 实体

    · 1.4.2.2 值对象

    · 1.4.2.3 聚合

    · 1.4.2.4 工厂

    · 1.4.2.5 仓储

    · 1.4.2.6 领域服务

·1.5 快速确立上下文边界的方法

· 1.5.1 上下文边界的定义和表达

· 1.5.2 领域归属-责任驱动法

· 1.5.3 领域联系-协作驱动法

战术设计

2 领域模型转化成数据模型的方法

· 2.1 通用建模方法

    · 2.1.1 彩色uml建模法

    · 2.1.2 uml建模法的运用

· 2.2 通用建模技巧

    · 2.2.1 二级结构

    · 2.2.2 type通用结构

3 代码如何体现领域模型

· 3.1 排版规范

        · 3.1.1 system、module、package的业务组织方式

        · 3.1.2 method,class等命名方式实体，值对象等等接口定义方式

· 3.2 领域构造规范

    · 3.2.1 实体

        · 3.2.1.1 实体的唯一标识，属性，行为和规约

        · 3.2.1.2 实体行为的粒度和完整

        · 3.2.1.3 实体的构造、存储和获取

    · 3.2.2 值对象

        · 3.2.2.1 构造和获取

        · 3.2.2.2 值对象实例的多变化、在架构之间的传递。

    · 3.2.3 领域服务

        · 3.2.3.1 两种领域服务的实现

· 3.3 领域生命周期规范

    · 3.3.1 聚合

        · 3.3.1.1 聚合的作用，如何构造和获取

        · 3.3.1.2 聚合的粒度、组成范围(业务范围的控制)

        · 3.3.1.3 聚合行为定义和实体行为的区别、聚合如何暴露实体的行为

    · 3.3.2 工厂

        · 3.3.2.1 工厂的作用

        · 3.3.2.2  build+factory两种模式

    · 3.3.3 仓储

        · 3.3.3.1 狭义仓储

        · 3.3.3.2 广义仓储

4 架构的实战应用

· 4.1 多层架构

    · 4.1.1 整体5层架构

    · 4.1.2 应用层

    · 4.1.3 领域层

    · 4.1.4 基础设施层

    · 4.1.5 SPI层

    · 4.1.6 Controller层

 · 4.2 DDD 和 Spring 架构的结合

    · 4.2.1 new 和 Spring 容器间的艰难选择

    · 4.2.2 和 Spring 架构的结合

    · 4.2.3 依赖倒置和 Spring 框架的结合

· 4.3 简单六边形架构

    · 4.3.1 上游复杂多变

    · 4.3.2 核心保持不变

    · 4.3.3 下游薄防腐层的出现

· 4.4 复杂六变形架构

    · 4.4.1 流程编排的出现

    · 4.4.2 核心不变粒度进行了优化

    · 4.4.3 SPI层的演进

· 4.5 读写分离架构

    · 4.5.1. 读写分离架构的思考

    · 4.5.2 读写分离架构的实现