text: 为什么使用资源库？
  如果完全按照领域模型的角度，完全通过遍历对象的方法来获取所有关联的对象。这种模型会过于错综复杂。对象嵌套的层级或者关联的层级非常深。例如通过Customer.order.product.price层层遍历来获取当时客户订单的商品的价格。
  那如果完全按照数据库模型的角度，模型中的对象不需要完全连接起来，对象关系网就能保持在一个可控范围。但是这又会回到之前传统开发模式中，零散的使用各个DAO从各个表抽取数据自行拼凑出我们想要的模型。
  这里就会出现一个问题，Customer类需要保持客户所有已订的Order，还是通过CustomerID在数据库中查找Order列表呢？
  客户需要一种有效的方式来获取已存在的领域对象的引用。如果基础设施提供了这方面的遍历，那么开发人员可能会增加很多可遍历的关联，这会使模型变得非常混乱。另一方面，开发人员可能使用查询从数据库中提取他们所需的数据，或是直接提取具体的对象，而不是通过聚合的根来得到这些对象。这样就导致领域逻辑进入查询和客户代码中，而实体和值对象变成了单纯的数据容器。采用大多数处理数据库访问的技术复杂性很快就会使客户代码变得混乱，这将导致开发人员简化领域层，最终使模型变得无关紧要。
  我们需要找到一个恰当的方式。
  对值对象的全局搜索通常是没有意义的。如果确实需要在数据库中搜索一个已知的值对象，那么值得考虑一下，搜索结果可能实际上是一个实体，尚未识别出它的标识。
  在所有持久化对象中，有一小部分必须通过基于对象属性的搜索来全局访问。当很难通过遍历的方式来访问某些聚合根的时候，就需要这种访问方式，它们通常是实体，有时可能是具有复杂内部结构的值对象。而其他对象则不适合使用这种访问方式，因为这会混淆它们之间的重要区别。随意的数据库查询会破坏领域对象的封装和聚合。技术基础设施的数据访问机制的暴露会增加客户的复杂度，并妨碍模型驱动的设计。
  我们应该将资源库看作一个对象的集合。
  这样一来客户就只需与一个简单的、易于理解的接口进行对话，并根据模型向这个接口提出它的请求。
  为每种需要全局访问的对象类型创建一个资源库，这个资源库相当于该类型的所有对象在内存的一个集合的“替身”。通过一个众所周知的全局接口来提供访问。提供添加和删除对象的方法，用这些方法来封装在数据存储中实际插入和删除数据的操作。根据提供具体条件来挑选对象的方法，并返回属性值满足条件的对象或者对象集合，从而将实际的存储和查询技术封装起来。只为那些确实需要直接访问的聚合根提供资源库，让客户始终聚焦于模型，而将所有对象的存储和访问操作交给资源库来完成。
  让用户无感知的，以为就在内存中使用一个集合一样。
  某些类型的汇总。
  对类型进行抽象，比如有奔驰车宝马车，不应有两种资源库，而应该是只有一个抽象车类的资源库。
  充分利用与客户进行解耦。
  将事务的控制权交给客户。
  为客户提供了一个简单的模型，可用来获取持久化对象并管理他们的生命周期。
  他们将应用程序和领域设计与持久化技术进行解耦。
  它们体现了有关对象访问的设计决策。
  很容易测试，将利用集合直接替换资源库进行测试。
  对事务的管理绝对不应该放在领域模型和领域层中。通常来说，与领域模型相关的操作都非常的细粒度，以致于无法用于管理事务。另外，领域模型也不应该意识到事务的存在。通常我们将事务放在应用层，然后为每个主要的用例创建一个门面，一个用例对应一个门面业务方法，如果所有操作安全完成的话，门面中的业务方法提交事务，否则失败回滚。
  关于DDD的理解各有不同，欢迎网友评论一起探讨。