DDD中的工厂和设计模式中的工厂不是同一个概念
聚合
聚合表达的是真实世界中整体和部分的关系，例如订单与订单明细。
在关系型数据库中，没有办法在一个字段中表达一对多的关系，因此必须将订单明细设计成另外一张表。在领域模型设计中，我们又将其还原到真实世界中，以聚合的形式进行设计。在领域模型中将订单明细设计成订单中的一个属性。
@Data
public class Order{
private Set<Items> items;
}
| 行为 | 操作 |
|---|---|
| 创建订单 | 将订单明细创建在订单中 |
| 保存订单 | 同时保存订单表与订单明细表，并放在同一事务中 |
| 查询订单 | 同时查询订单表和订单明细表，并将其装配成一个订单对象 |
也就是说对订单明细的操作是封装在订单对象内部的设计实现，对于客户程序来说去使用订单对象就好了，这就包括了作为属性去访问订单对象中的订单明细，而不再需要关注它内部是如何操作的。
聚合体现的是整体与部分的关系，正是因为有这样的关系，在操作整体的时候，整体就封装了部分的操作。所谓的整体和部分的关系：当整体不存在时，部分就变得没有了意义。部分是整体的一个部分，与整体有相同的生命周期。
例如只有创建了这个订单，才会有订单明细，当删除了这个订单，那么订单明细就变得没有意义，需要同时删除掉订单明细。在比如订单与用户的关系不是聚合，因为用户不是创建订单时才存在的，而是在创建订单时早已存在。
通过聚合的设计，可以真实反应现实世界的状况，提高软件设计的质量，有效降低日后变更的成本。
聚合根
聚合根——外部访问的唯一入口
有了聚合关系，部分就会被封装在整体里面。这时就会形成一种约束及外部程序不能跳过整体去操作部分。对部分的操作都必须要通过整体，这时整体就成为外部访问的唯一入口，被称为“聚合根”。
一旦将对象间的关系设计成为聚合，那么外部程序只能访问聚合根，而不用访问聚合内部的其他对象。这样带来的好处就是聚合内部的业务逻辑发生变更时，只与聚合内部有关，而与外部程序无关。从而有效降低了变更的维护成本，提高了系统设计质量。
但是这样的设计有时是有效的，但并非都有效。比如在管理订单时，对订单进行增删改聚合是有效的。但是如果要统计销量，分析销售趋势，统计销售占比时。如果每次对订单明细的汇总与统计都必须经过订单的查询，必然使得查询统计变得效率极低而无法使用。
因此领域驱动设计通常适用于增删改的业务操作，但不适用于分析统计。增删改的业务可以采用领域驱动的设计，但在非增删改的分析汇总场景中，则不必采用领域驱动的设计，直接sql查询就好了。也不必在遵循聚合的约束。
聚合的落地
真正将聚合落地，还需要两个重要的组件——仓库和工厂；
仓库
例如现在创建了一个订单，订单包含了多条订单明细，并将他们做成了一个聚合。当订单完成创建需要同时保存订单表与订单明细表，并将其做到一个事务，这时候谁来负责保存并对其添加事务呢？
过去采用的是贫血模型：通过订单DAO与订单明细DAO去完成数据库的保存，又订单Service去添加事务，这样的设计没有聚合，缺乏封装性，不利于日后的维护。
采用领域驱动设计：通常就会实现一个仓库（Repository）去完成对数据库的访问。订单与订单明细的保存就会封装在订单仓库中去实现。
仓库与DAO的区别：
DAO保存与查询的是单表。若是查询多表的，一般在sql中通过join连接来进行实现。
仓库在查询时，只是简单地查询单表，不会进行Join连接，一般是在代码中进行补填其他表数据。仓库不是简单的将该对象返回给客户程序，并且根据实际情况会有一个缓存的功能。
工厂
在查询仓库时一般会通过查询来补填其他数据。这时候这些创建装配的工作都会交给另外一个组件工厂来完成。
注意：DDD中的工厂和设计模式中的工厂并不是一个概念。
设计模式：将被调方设计成一个接口下的多个实现，将这些实现放入到工厂中，工厂负责通过key值找到对应的实现类，创建出来返回给调用方，从而降低了调用方与被调用方的耦合度。
DDD：主要是通过装配创建领域对象，是领域对象生命周期的起点。
举例说明：
- 订单仓库将任务交给订单工厂，订单工厂会分别调用订单DAO、订单明细DAO和用户DAO去进行查询；
- 将订单明细对象与用户对象，分别set到订单对象的“订单明细”和“用户”属性中；
- 订单工厂将装配好的订单对象返回给订单仓库；
复杂的业务中，领域模型出现了继承多态的情况（即一个订单中有多个订单类型）。
- 无状态的校验可以交由领域对象的充血方法完成。
- 有状态的校验可以交由工厂实现。
- 调用其他领域服务或者RPC的数据填充交由工厂完成。
总结
通过仓库和工厂，对原有的DAO进行一层封装，在保存、装载、查询等操作中，加入聚合、装配等操作并将这些操作封装起来，对上层应用来进行屏蔽。
