DDD-Learning (1)

聚合

     　聚合（Aggregate）是领域驱动设计中非常重要的一个概念。简单地说，聚合是这样一组领域对象（包括实体和值对象），这组领域对象联合起来表述一个完整的领域概念。比如，根据Eric Evans《领域驱动设计》一书中的例子，一辆车包含四个轮子，轮子离开“车”就毫无意义，此时这个联合体就是聚合，而“车”就是聚合根（Aggregate Root）。

       　每个聚合都有一个根实体（聚合根，Aggregate Root），这个根实体是聚合所表述的领域概念的主体，外部对象需要访问聚合内的实体时，只能通过聚合根进行访问，而不能直接访问。从技术角度考虑，聚合确定了实体生命周期的关注范围，即当某个实体被创建时，同时需要创建以其为根的整个聚合，而当持久化某个实体时，同样也需要持久化整个聚合。比如，在从外部持久化机制重建“客户”对象的同时，也需要将其所拥有的“信用卡”赋给“客户”实体（具体如何操作，根据需求而定）。不要去关注聚合内实体的生命周期问题，如果你真的这么做了，那么你就需要考虑下你的设计是否合理。

1. 领域对象从无到有的创建，不是针对某个实体的，而是针对某个聚合的
2. 领域对象的持久化（通常所说的“保存”）、重建（通常所说的“查询”）和销毁（通常所说的“删除”）也不是针对某个实体的，而是针对某个聚合的.

仓储

      仓储（Repository），顾名思义，就是一个仓库，这个仓库保存着领域模型的实体对象。在业务处理的过程中，我们有可能需要把正在参与处理过程的对象保存到仓储中，也有可能会从仓储中读取需要的实体对象，抑或将对象直接从仓储中删除。

      如果实体A是聚合根，而B是该聚合中的一个实体，而你的设计希望绕过A而直接从仓储中获得B，那么，这就是一个信号，预示着你的设计可能存在问题，也就是说，B很有可能被当成是另一个聚合的根，而这个聚合只有一个对象，就是B本身。由此看来，聚合的划分与仓储的设计，在领域驱动设计的实践中是非常重要的内容。

     工厂是从无到有地创建对象，从代码上看，工厂里充斥着new关键字，用以创建对象，当然，工厂的职责并不完全是new出一个对象那么简单。而仓储则更偏向于对象的保存和获得，在获得的时候，同样也会有新的对象产生，这个新的对象与保存进去的对象相比，引用不同了，但数据和业务ID值（也就是我们常说的实体键）是不变的，因此，在领域层看来，从仓储中读取得到的对象与当时保存进去的对象并没有什么两样。

    你可能已经体会到，仓储就是一个数据库，它与数据库一样，有读取、保存、查询、删除的操作。我只能说，你已经了解到仓储的职能，并没有了解到它的角色。仓储是领域层与基础结构层的一个衔接组件，领域层通过仓储访问外部存储机制，这样就使得领域层无需关心任何技术架构上的实现细节。因此，仓储这个角色的职责不仅仅是读取、保存、查询、删除，它还解耦了领域层与基础结构层。在实践中，可以使用依赖注入的方式，将仓储实例注入到领域层，从而获得灵活的体系结构。

仓储的实现

      将仓储接口定义在实体、值对象和服务所在的领域层。既然仓储需要与外部存储机制打交道，那么它必定需要知道技术架构方面的细节，而将其定义在领域层，就会使得领域层依赖于具体的技术实现方式，这样就会使领域层变得“不纯净” 了。其实不然！请注意，我们这里仅仅只是将仓储的接口定义在了领域层，而不是仓储的具体实现（Concrete Repository）。更通俗地说，接口作为系统架构的基础元素，决定了整个系统的架构模式，而基于接口的具体实现只不过是一种可替换的组件，它不能成为系统架构中的一部分。由于领域层需要用到仓储，我便将仓储的接口定义在了领域层。当然，从.NET的实现技术考虑，你可以新建一个Class Library，并将上述接口定义在这个Class Library中，然后在领域层和仓储的具体实现中分别引用这个Class Library

仓储的实现可以用下图表述：