1. 引言

DDD中Repository这个单词，主要有两种翻译：资源库和仓储，本文取仓储之译。

说到仓储，我们肯定就想到了仓库，仓库一般用来存放货物，而仓库一般由仓库管理员来管理。当工厂生产了一批货物时，只需交给仓库管理员即可，他负责货物的堆放；当需要发货的时候，仓库管理员负责从仓库中捡货进行货物出库处理。当需要库存盘点时，仓库管理员负责核实货物状态和库存。换句话说，仓库管理员负责了货物的出入库管理。通过仓库管理员这个角色，保证了仓库和工厂的独立性，工厂只需要负责生产即可，而至于货物如何存放工厂无需关注。

而我们要讲的仓储就类似于仓库管理员，只不过它负责的不再是货物的管理，而是聚合的管理，仓储介于领域模型和数据模型之间，主要用于聚合的持久化和检索。它隔离了领域模型和数据模型，以便我们关注于领域模型而不需要考虑如何进行持久化。

2. DDD中的仓储

2.1. 仓储的集合特性

仓储代表一个聚合的集合，其行为与.Net集合一样，仓储用来存储和删除聚合，但同时提供针对聚合的显式查询以及汇总。

2.2. 仓储与数据访问层的区别

仓储限定了只能通过聚合根来持久化和检索领域对象，以确保所有改动和不变性由聚合处理。
仓储通过隐藏聚合持久化和检索的底层技术实现领域层的的持久化无关性（即领域层不需要知道如何持久化领域对象）。
仓储在数据模型和领域模型定义了一个边界。

2.3. 仓储举例

下面我们首先来看一个简单仓储的定义：

namespace DomainModel{ 
public interface ICustomerRepository{ 
Customer FindBy(Guid id); 
void Add(Customer customer); void Remove(Customer customer);}
}

通常来说，仓储由应用服务层调用。仓储定义应用服务执行业务用例时需要的所有的数据访问方法。而仓储的实现通常位于基础架构层，由持久化框架来支撑。以下的仓储实现是借助于ORM框架Nhibernate的ISession接口，它扮演一个的网关角色，负责领域模型和数据模型的映射。

namespace Infrastructure.Persistence {  
  public class CustomerRepository : ICustomerRepository {      
  
    private ISession _session;   
         
         public CustomerRepository (ISession session) {_session = session;}    
     
        public IEnumerable<Customer> FindBy (Guid id)            return _session.Load<Order> (id);}      
      
        public void Add (Customer customer) {_session.Save (customer);}        public void Remove (Customer customer) {_session.Delete (customer);}}
}

从上面我们可以看出，将领域模型的持久化转移到基础设施层，隐藏了领域模型的技术复杂性，从而使领域对象能够专注于业务概念和逻辑。

2.4. 仓储的误解

仓储也存在很多误解，许多人认为其是不必要的抽象。当应用于简单的领域模型时，可以直接使用持久化框架来进行数据访问。然而当对复杂的领域模型进行建模时，仓储是模型的扩展，它表明聚合检索的意图，可以对领域模型进行有意义的读写，而不是一个技术框架。

也有很多人认为仓储是一种反模式，因为其隐藏了基础持久化框架的功能。而恰巧这正是仓储的要点。基础持久化框架提供了开放的接口用于对数据模型的查找和修改，而仓储通过使用定义的命名查询方法来限制对聚合的访问。通过使查询显式化，就更容易调整查询，且更重要的是仓储明确了查询的意图，便于领域专家理解。举个例子：我们在仓储中定义了一个方法GetAllActiveUsers()与sql语句select * from users where isactive = 1或var users =db.Users.Where(u=>u.IsActive ==1)相比，很明显仓储的方法命名就能让我们明白了查询的意图：查询所有处于Active状态的用户。除了查询，仓储仅暴露必要的持久化方法而不是提供所有的CURD方法。

2.5. 仓储的要点

仓储的要点并不是使代码更容易测试，也不是为了便于切换底层的持久化存储方式。当然，在某种程度上，这也的确是仓储所带来的利好。仓储的要点是保持你的领域模型和技术持久化框架的独立性，这样你的领域模型可以隔离来自底层持久化技术的影响。如果没有仓储这一层，你的持久化基础设施可能会泄露到领域模型中，并影响领域模型完整性和最终一致性。

3. 领域模型 VS 数据模型

如果选择关系型数据库作为持久化存储，我们可以借助于ORM框架来实现领域模型和数据模型之间的映射和持久化操作。

而ORM又是什么呢？

按照文章开头中的例子，如果仓储对应仓库管理员的角色，那ORM就相当于仓库机器人，而仓库就相当于数据库。为了方便不同商品的归类存放，对仓库进行分区，分区就相当于数据表。当公司接到一笔订单做发货处理时，销售员将发货通知单告知仓库管理员，仓库管理员再分配ORM机器人进行捡货。很显然，ORM机器人必须能够识别发货通知单，将发货通知单中的商品对应到仓库中存储的货物。这里面发货通知单就相当于领域模型，而仓库中存储的货物就属于数据模型。

相信基于上面的比喻，我们对ORM有了基本的认识。ORM，全称是Object Relational Mapping，对象关系映射。ORM的前提是，将对象的属性映射到数据库字段，将对象之间的引用映射到数据库表的关系。换句话说，ORM负责将代码中定义的对象和关系映射到数据库的表结构中去，并在进行数据访问时再将表数据映射到代码中定义的对象，借助ORM我们不需要去手动写SQL语句就可以完成数据的增删改查。ORM仅仅抽象了关系数据模型，它只是以面向对象的方式来表示数据模型，以方便我们在代码中轻松地处理数据。

下面我们来探讨一下数据模型与领域模型的异同。关系数据库中的数据模型，它由表和列组成，它只是简单的存储结构，用于保存领域模型某个时间点的状态。数据模型可以分散在几个表甚至几个数据库中。此外，可以使用多种形式的持久化存储，例如文件、web服务器、关系数据库或NoSQL。领域模型是对问题域的抽象，具有丰富的语言和行为，由实体和值对象组成。对于一些领域模型，可能与数据模型相似，甚至相同，但在概念上它们是非常不同的。ORM与领域模型无关。仓储的作用就是将领域模型与数据模型分开，而不是让它们模糊成一个模型。ORM不是仓储，但是仓储可以使用ORM来持久化领域对象的状态。

如果你的领域模型与你的数据模型类似，ORM可以直接映射领域模型到数据存储，否则，则需要对ORM进行额外的映射配置。

4. 仓储的定义和实现

上面也提到过，我们一般在领域层定义仓储接口，在基础设施层实现仓储，以隔离领域模型和数据模型。

4.1. 仓储方法需明确

仓储是原则上是领域模型与持久化存储之间明确的契约，仓储定义的接口方法不仅仅是CURD方法。它是领域模型的扩展，并以领域专家所理解的术语编写。仓储接口的定义应该根据应用程序的用例需求来创建，而不是从类似CURD的数据访问角度来构建。

我们来看一段代码：

namespace DomainModel {   
 public interface ICustomerRepository {       
      Customer FindBy (Guid id);     
      IEnumerable<Customer> FindAllThatMatch (Query query);      
      IEnumerable<Customer> FindAllThatMatch (String hql);  
      void Add (Customer customer);}
}

以上仓储定义了一个FindAllThatMatch方法以支持客户端以任何方式查询领域对象。这个方法的设计思想无可置否，灵活且可以扩展，但是它并没有明确的表明查询的意图，我们就失去了对查询的控制。为了真正了解如何使用这些方法，开发人员需要跟踪相关调用堆栈，才能知悉方法的意图，更别说出现性能问题时如何着手优化了。因为仓储定义的接口方法过于宽泛且不具体，它模糊了领域的的概念，所以定义这样的一个接口方法是无意义的。

我们可以如下改造：

namespace DomainModel {   

 public interface ICustomerRepository {       
 
  Customer FindBy (Guid id);      
    IEnumerable<Customer> FindAllThatAreDeactivated ();    
    IEnumerable<Customer> FindAllThatAreOverAllowedCredit ();   
    void Add (Customer customer);}
}

通过以上改造，我们通过方法的命名来明确查询的意图，符合通用语言的规范。

4.2. 泛型仓储

在实践中我们可能会发现，为每一个聚合定义一个仓储会导致重复代码，因为大部分的数据操作都是类似的。为了代码重用，泛型仓储就应时而生。

泛型仓储举例：

namespace DomainModel {   

 public interface IRepository<T> where T : EntityBase {    
     T GetById (int id);IEnumerable<T> List ();IEnumerable<T> List (Expression<Func<T, bool>> predicate);  
        void Add (T entity);  
        void Delete (T entity);     
        void Edit (T entity);}   
         public abstract class EntityBase {      
         
           public int Id { get; protected set; }}
}

泛型仓储实现：

namespace Infrastructure.Persistence { 
   public class Repository<T> : IRepository<T> where T : EntityBase {       
    private readonly ApplicationDbContext _dbContext;    
       public Repository (ApplicationDbContext dbContext) {_dbContext = dbContext;}      
       
         public virtual T GetById (int id) {      
               return _dbContext.Set<T> ().Find (id);}   
               
        public virtual IEnumerable<T> List () {        
        
          return _dbContext.Set<T> ().AsEnumerable ();}       
        
        public virtual IEnumerable<T> List (Expression<Func<T, bool>> predicate) {       
             return _dbContext.Set<T> ().Where (predicate).AsEnumerable ();}     
       public void Insert (T entity) {_dbContext.Set<T> ().Add (entity);_dbContext.SaveChanges ();}       
       
        public void Update (T entity) {_dbContext.Entry (entity).State = EntityState.Modified;_dbContext.SaveChanges ();}    
        
       public void Delete (T entity) {_dbContext.Set<T> ().Remove (entity);_dbContext.SaveChanges ();}}
}

通过定义泛型仓储和默认的实现，很大程度上进行了代码重用。但是，尝试将泛型仓储应用所有仓储并不是一个好的主意。对于简单的聚合我们可以直接使用泛型仓储来简化代码。但对于复杂的聚合，泛型仓储可能就会不太适合，如果基于泛型仓储的方法进行数据访问，就会模糊对聚合的访问意图。

对于复杂的聚合，我们可以重新定义：

namespace DomainModel {  

  public interface ICustomerRepository {       
  
         Customer FindBy (Guid id);        
   
      IEnumerable<Customer> FindAllThatAreDeactivated ();    
       void Add (Customer customer);}
}

在实现时，我们可以引用泛型仓储来避免代码重复。

namespace Infrastructure.Persistence {   

 public class CustomerRepository : ICustomerRepository {    
     private IRepository<Customer> _customersRepository;  
     
           public Customers (IRepository<Customer> customersRepository) {_customersRepository = customersRepository;}        // ....
           public IEnumerable<Customer> FindAllThatAreDeactivated () {_customersRepository.List(c => c.IsActive == false);}      
            public void Add (Customer customer) {_customersRepository.Add (customer);}}
}

通过这种方式，我们即明确了查询了意图，又简化了代码。

4.3. IQueryable Vs IEnumerable

在定义仓储方法的返回值时，我们可能会比较疑惑，是应该直接返回数据（IEnumerable）还是返回查询（IQueryable）以便进行进一步的细化查询？返回IEnumerable会比较安全，但IQueryable提供了更好的灵活性。事实上，如果使用IQueryable作为返回值，我们仅提供一种读取数据的方法即可进行各种查询。
但是这种方式就会引入一个问题，就是业务逻辑会渗透到应用层中去，并出现大量重复。比如，在实体中我们一般使用IsActive或IsDeleted属性来表示软删除，而一旦实体中的某条数据被删除，那么UI中基本不会再显示这条数据，那对于实体的查询都需要包含类似Where(c=> c.IsActive)的linq表达式。对于这种问题，我们最好在仓储中的方法中，比如List()或者ListActive()做默认处理，而不是在应用服务层每次去指定查询条件。
但具体是返回 IQueryable还是IEnumerable每个人的看法不一，具体可参考Repository 返回 IQueryable？还是 IEnumerable？。

5. 事务管理和工作单元

事物管理主要是应用服务层的关注点。然而，因为仓储和事物管理紧密相关的。仓储仅关注单一聚合的管理，而一个业务用例可能会涉及到多种的聚合。

事物管理由UOW（Unit of Work）处理。UOW模式的作用是在业务用例的操作中跟踪聚合的所有更改。一旦发生了更改，UOW就使用事务来协调持久化存储。为了确保数据的完整性，如果提交数据失败，则会回滚所有更改，以确保数据保持有效状态。

而关于UOW又是一个复杂的话题，我们后续再讲。

6. 仓储的反模式（注意事项）

不要支持临时查询（ad hoc query）
仓储不应该开放扩展，不要为了支持多种形式的查询，定义比较宽泛的查询方法，它不仅不能明确表达仓储查询的意图，更可能会导致查询性能。
延迟加载是一种设计臭味
聚合应围绕不变性构建，并包含所有必需的属性去支持不变性。因此，当加载聚合时，要么加载所有，要么一个也不加载。如果您有一个关系数据库并且正在使用ORM作为数据模型，那么您可能能够延迟加载一些领域对象属性，这样就可以推迟加载不需要的聚合部分。但是，这样做的问题是，如果您只能部分加载聚合，可能会导致您的聚合边界错误。
不要使用聚合来实现报表需求
报表可能会涉及到多个类型的聚合，而仓储是处理单一聚合的。另外仓储是基于事务的，可能会导致报表的性能问题。