聚合根、实体和值对象
实体有ID标识，有生命周期，有状态（用值对象来描述状态），实体通过ID进行区分
聚合根是实体，聚合根的ID全局唯一标识，聚合根下面的实体的ID在聚合根内唯一即可
值对象的核心本质是值，与是否有复杂类型无关，值对象没有生命周期，通过两个值对象的值是否相同区分是否是同一个值对象，值对象主要用于描述实体的状态
聚合代表上下文边界
聚合Aggregate就是一组相关对象的集合，我们把它作为数据修改和访问的单元。每个聚合都会有一个聚合根和聚合的边界Boundary，边界定义了在一个聚合里面内部应该有哪些实体，哪些子实体对象。定义边界的原因是我们期望对一个聚合的访问是通过聚合根点进行的，聚合里面的子实体对外界是完全封闭的。对于外部对象不应该去访问到一个聚合边界里面的子实体。
(img)
聚合设计的原则
- 聚合是用来封装真正的不变性，而不是简单的将对象组合在一起；
- 聚合应尽量设计的小，主要因为业务决定聚合，业务改变聚合，尽可能小的拆分，可以避免重构，重新拆分
- 聚合之间的关联通过ID，而不是对象引用；
- 聚合内强一致性，聚合之间最终一致性；
聚合是用来封装真正的不变性，而不是简单的将对象组合在一起
这个原则，就是强调聚合的真正用途除了封装我们本身所关心的信息外，最主要的目的是为了封装业务规则，保证数据的一致性。在我看来，这一点是设计聚合时最重要和最需要考虑的点；当我们在设计聚合时，要多想想当前聚合封装了哪些业务规则，实现了哪些数据一致性。所谓的业务规则是指，比如一个银行账号的余额不能小于0，订单中的订单明细的个数不能为0，订单中不能出现两个明细对应的商品ID相同，订单明细中的商品信息必须合法，商品的名称不能为空，回复被创建时必须要传入被回复的帖子（因为没有帖子的回复不是一个合法的回复），等；
聚合应尽量设计的小
这个原则，更多的是从技术的角度去考虑的。作者通过一个例子来说明，该例子中，一开始聚合设计的很大，包含了很多实体，但是后来发现因为该聚合包含的东西过多，导致多人操作时并发冲突严重，导致系统可用性变差；后来开发团队将原来的大聚合拆分为多个小聚合，当然，拆分为小聚合后，原来大聚合内维护的业务规则同样在多个小聚合上有所体现。所以实现了既能解决并发冲突的问题，也能保证让聚合来封装业务规则，实现模型级别的数据一致性；另外，回复中的一位道友“殇、凌枫”提到，聚合设计的小还有一个好处，就是：业务决定聚合，业务改变聚合。聚合设计的小除了可以降低并发冲突的可能性之外，同样减少了业务改变的时候，聚合的拆分个数，降低了聚合大幅重构（拆分）的可能性，从而能让我们的领域模型更能适应业务的变化。
聚合之间通过ID关联
这个原则，是考虑到，其实聚合之间无需通过对象引用的方式来关联；
1 首先通过引用关联，会导致聚合的边界不够清晰，如果通过ID关联，由于ID是值对象，且值对象正好是用来表达状态的；所以，可以让聚合内只包含只属于自己的实体或值对象，那这样每个聚合的边界就很清晰；每个聚合，关心的是自己有什么信息，自己封装了什么业务规则，自己实现了哪些数据一致性；
2 如果通过引用关联，那需要实现LazyLoad的效果，否则当我们加载一个聚合的时候，就会把其关联的其他聚合也一起加载，而实际上我们有时在加载一个聚合时，不需要用到关联的那些聚合，所以在这种时候，就给性能带来一定影响，不过幸好我们现在的ORM都支持LazyLoad，所以这点问题相对不是很大；
3 你可能会问，聚合之间如果通过对象引用来关联，那聚合之间的交互就比较方便，因为我可以方便的直接拿到关联的聚合的引用；是的，这点是没错，但是如果聚合之间要交互，在经典DDD的架构下，一般可以通过两种方式解决：1）如果A聚合的某个方法需要依赖于B聚合对象，则我们可以将B聚合对象以参数的方式传递给A聚合，这样A对B没有属性上的关联，而只是参数上的依赖；一般当一个聚合需要直接访问另一个聚合的情况往往是在职责上表明A聚合需要通知B聚合做什么事情或者想从B聚合获取什么信息以便A聚合自己可以实现某种业务逻辑；2）如果两个聚合之间需要交互，但是这两个聚合本身只需要关注自己的那部分逻辑即可，典型的例子就是银行转账，在经典DDD下，我们一般会设计一个转账的领域服务，来协调源账号和目标账号之间的转入和转出，但源账号和目标账号本身只需要关注自己的转入或转出逻辑即可。这种情况下，源账号和目标账号两个聚合实例不需要相互关联引用，只需要引入领域服务来协调跨聚合的逻辑即可；
4 如果一个聚合单单保存另外的聚合的ID还不够，那是否就需要引用另外的聚合了呢？也不必，此时我们可以将当前聚合所需要的外部聚合的信息封装为值对象，然后自己聚合该值对象即可。比如经典的订单的例子就是，订单聚合了一些订单明细，每个订单明细包含了商品ID、商品名称、商品价格这三个来自商品聚合的信息；此时我们可以设计一个ProductInfo的值对象来包含这些信息，然后订单明细持有该ProductInfo值对象即可；实际上，这里的ProductInfo所包含的商品信息是在订单生成时对商品信息的状态的冗余，订单生成后，即便商品的价格变了，那订单明细中包含的ProductInfo信息也不会变，因为这个信息已经完全是订单聚合内部的东西了，也就是说和商品聚合无关了。
5 实际上通过ID关联，也是达到设计小聚合的目标的一种方式；
聚合内强一致性，聚合之间最终一致性
这个原则主要的背景是：如果用CQRS+Event Sourcing的架构来实现DDD，那聚合之间因为通过Domain Event（领域事件）来实现交互了，所以同样也不需要聚合与聚合之间的对象引用，同时也不需要领域服务了，因为领域服务已经被Process（流程聚合根）和Process Manager（流程管理器，无状态）所替代。流程聚合根，负责封装流程的当前状态以及流程下一步该怎么走的逻辑，包括流程遇到异常时的回滚处理逻辑；流程管理器，无状态。负责协调流程中各个参与者聚合根之间的消息交互，它会接受聚合根产生的domain event，然后发送command。另外一方面，由于CQRS的引入，使得我们的domain只需要处理业务逻辑，而不需要应付查询相关的需求了，各种查询需求专门由各种查询服务实现；所以我们的domain就可以非常瘦身，仅仅只需要通过聚合根来封装必要的业务规则（保证聚合内数据的强一致性）即可，然后每个聚合根做了任何的状态变更后，会产生相应的领域事件，然后事件会被持久化到EventStore，EventStore用来持久化所有的事件，整个domain的状态要恢复，只需要通过Event Sourcing的方式还原即可；另外，当事件持久化完成后，框架会通过事件总线将事件发布出去，然后Process Manager就可以响应事件，然后发送新的command去通知相应的聚合根去做必要的处理；
上面这个过程可以在任何一个CQRS的架构图（包括enode的架构图）中找到，我这里就不贴图了。enode中对经典的转账场景用这种思路实现了一下，有兴趣可以去下载enode源代码，然后看一下其中的BankTransferSample这个例子就清楚了。另外，因为事件的响应和Command的发送是异步的，所以，这种架构下，聚合根的交互是异步的；
需要再次强调的一点是，聚合如果只需要关注如何实现业务规则而不需要考虑查询需求所带来的好处，那就是我们不需要在domain里维护各种统计信息了，而只要维护各种业务规则所潜在的必须依赖的状态信息即可；举个例子，假如一个论坛，有版块和帖子，以前，我们可能会在版块对象上有一个帖子总数的属性，当新增一个帖子时，会对这个属性加1；而在CQRS架构下，domain内的版块聚合根无需维护总帖子数这个统计信息了，总帖子数会在查询端的数据库独立维护；
设计聚合时，要多想想当前聚合封装了哪些业务规则，实现了哪些数据一致性。所谓的业务规则是指，比如一个银行账号的余额不能小于0，订单中的订单明细的个数不能为0，订单中不能出现两个明细对应的商品ID相同，订单明细中的商品信息必须合法，商品的名称不能为空，回复被创建时必须要传入被回复的帖子（因为没有帖子的回复不是一个合法的回复）等；
为什么要聚合根
在一个场景中（有界上下文），一群对象（聚合）有着一致的行为特征，彼此协调干着一件事，这群对象是一个聚合，其中协调者管理者是聚合根
聚合根、实体、值对象对象之间如何建立关联
聚合根到聚合根：通过ID关联；
聚合根到其内部的实体，直接对象引用；
聚合根到值对象，直接对象引用；
实体对其他对象的引用规则：1）能引用其所属聚合内的聚合根、实体、值对象；2）能引用外部聚合根，但推荐以ID的方式关联，另外也可以关联某个外部聚合内的实体，但必须是ID关联，否则就出现同一个实体的引用被两个聚合根持有，这是不允许的，一个实体的引用只能被其所属的聚合根持有；
值对象对其他对象的引用规则：只需确保值对象是只读的即可，推荐值对象的所有属性都尽量是值对象；
事件溯源
事件溯源模式有许多优点，包括：
事件是不变的，所以可以用只增加的方式去保存。用户界面，工作流或者初始化产生事件的过程就都可以不被干扰地进行，因为处理这些事件的工作任务可以在后台运行。而且，事务在执行时候不会造成冲突，这样就可以极大地改善应用程序的性能和可伸缩性，特别是对于用户展现层。
事件是描述已经发生的事件的简单实体，事件同时也包含一些描述事件的数据。 事件不会直接地把数据库中的数据更新掉，他们只是简单地被储存起来以备使用。这些事件使用和维护起来非常简单。
事件对领域专家有特殊的意义，然而可能领域专家没有明白数据库中各个表而导致复杂的实体关系被错误地映射了。数据表只是表现了系统的当前状况，但不是已经发生的事件。
事件溯源可以防止并发更新造成的冲突因为这种方式防止操作直接去更新数据库中的记录。然而，领域模型必须被设计得能够防止不一致状态的发生。
只增的事件数据存储方式为监视对数据库的操作提供了审查的途径，在任何时候都能通过重现事件的方式以实现物化视图或者规划，并且可以帮助检查和测试系统。并且，一些撤销操作的修正操作可以通过进行历史操作的反向操作来实现，而这个在一个仅仅记录当前状态的系统中是无法实现的。事件的列表也可以用来分析应用程序的性能情况和查看用户的行为趋势，或者用来挖取其他的商业信息。
事件和任务的解耦保证了系统的灵活性和扩展性。例如，一些处理事件的任务仅仅需要考虑事件数据库发布的事件本身属性和描述事件的数据。这种执行任务的方式和引发事件的操作是低耦合的。并且，多个任务都可以处理各自的事件。这样的话方便与其他的服务和系统的合作，只需要监听事件数据库发布的事件就可以了。然而，溯源的事件是在一个很低层次上，有的时候需要产生一系列事件。
例子分析1：订单模型
Order（一 个订单）必须有对应的客户信息，否则就不能称为一个有效的Order；同理，Order对OrderLineItem有不变性约束，Order也必须至少有一个OrderLineItem(一条订单明细)，否 则就不能称为一个有效的Order；另外，Order中的任何OrderLineItem的数量都不能为0，否则认为该OrderLineItem是无效 的，同时可以推理出Order也可能是无效的。因为如果允许一个OrderLineItem的数量为0的话，就意味着可能会出现所有 OrderLineItem的数量都为0，这就导致整个Order的总价为0，这是没有任何意义的，是不允许的，从而导致Order无效；所以，必须要求 Order中所有的OrderLineItem的数量都不能为0；那么现在可以确定的是Order必须包含一些OrderLineItem，那么应该是通 过引用的方式还是ID关联的方式来表达这种包含关系呢？这就需要引出另外一个问题，那就是先要分析出是OrderLineItem是否是一个独立的聚合 根。回答了这个问题，那么根据上面的规则就知道应该用对象引用还是用ID关联了。那么OrderLineItem是否是一个独立的聚合根呢？因为聚合根意 味着是某个聚合的根，而聚合有代表着某个上下文边界，而一个上下文边界又代表着某个独立的业务场景，这个业务场景操作的唯一对象总是该上下文边界内的聚合 根。想到这里，我们就可以想想，有没有什么场景是会绕开订单直接对某个订单明细进行操作的。也就是在这种情况下，我们 是以OrderLineItem为主体，完全是在面向OrderLineItem在做业务操作。有这种业务场景吗？没有，我们对 OrderLineItem的所有的操作都是以Order为出发点，我们总是会面向整个Order在做业务操作，比如向Order中增加明细，修改 Order的某个明细对应的商品的购买数量，从Order中移除某个明细，等等类似操作，我们从来不会从OrderlineItem为出发点去执行一些业 务操作；另外，从生命周期的角度去理解，那么OrderLineItem离开Order没有任何存在的意义，也就是说OrderLineItem的生命周 期是从属于Order的。所以，我们可以很确信的回答，OrderLineItem是一个实体。
例子分析2：帖子与回复的模型，做个对比，以便更好地理解。
不 变性分析：帖子和回复之间有不变性规则吗？似乎我们只知道一点是肯定的，那就是帖子和回复之间的关系，1：N的关系；除了这个之外，我们看不到任何其他的 不变性规则。那么这个1：N的对象关系是一种不变性规则吗？不是！首先，一个帖子可以没有任何回复，帖子也不对它的回复有任何规则约束，它甚至都不知道自 己有多少个回复；再次，发表了一个回复和帖子也没有任何关系；其次，发表回复对帖子没有任何改变；从业务场景的角度去分析，我们有发表帖子的场景，有发表 回复的场景。当在发表回复的时候，是以回复为主体的，帖子只是这个回复里所包含的必要信息，用于说明这个回复是对哪个帖子的回复。这些都说明帖子和回复之 间找不出任何不变性约束的规则；因为帖子和回复都有各自独立的业务场景的需要，所以可以很容易理解它们都是独立的聚合根；那也很容易知道该如何建立他们之 间的关联了，但是我们要尽量减少关联，所以只保留回复对帖子的关联即可；帖子没有任何必要去保存一个回复的ID的列表；那么你可能会说，当我删除一个帖子 后，回复应该是没有存在的意义的呀？不对，不是没有存在的意义，而是删除了帖子后导致了回复对帖子的关联信息的缺失，导致数据不一致。这是因为帖子和回复 之间有一种必然的联系（1：N），回复一定会有一个对应的帖子；但是回复有其自己的生命周期，不应该随着帖子的删除而级联删除。这种情况下，如果你删除了 帖子，就导致回复也成为了一条无效的数据；所以，我们绝对不允许删除任何聚合根，因为一旦你删除了聚合根，那就意味着与该聚合根相关的其他任何聚合根都会 有外键引用缺失的问题，会导致整个领域模型数据的不一致；所以，永远都不要删除聚合根；
