DDD理論學習系列（12）-- 倉儲

DDD理論學習系列——案例及目錄

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作為數據模型，那么您可能能夠延遲加載一些領域對象屬性，這樣就可以推遲加載不需要的聚合部分。但是，這樣做的問題是，如果您只能部分加載聚合，可能會導致您的聚合邊界錯誤。
不要使用聚合來實現報表需求
報表可能會涉及到多個類型的聚合，而倉儲是處理單一聚合的。另外倉儲是基于事務的，可能會導致報表的性能問題。

7. 總結

倉儲作為領域模型和數據模型的中介，它負責映射領域模型到持久化存儲。
倉儲實現了透明持久化，即領域層不需要關注領域對象如何持久化。
倉儲是一個契約，而不是數據訪問層。它明確表明聚合所必需的數據操作。
ORM框架不是倉儲。倉儲是一種架構模式。ORM用來以面向對象的方式來表示數據模型。倉儲使用ORM來協調領域模型和數據模型。
倉儲適用于具有豐富領域模型的限界上下文。對于沒有復雜業務邏輯的簡單限界上下文，直接使用持久化框架即可。
使用UOW進行事務管理。UOW負責跟蹤對象的狀態，倉儲在UOW協調的事務中進行實際的持久化工作。
倉儲用于管理單個聚合，它不應該控制事務。

參考資料：
領域驅動設計（DDD）的實踐經驗分享之持久化透明
 Repository Pattern--A data persistence abstraction
領域驅動設計（DDD）的實踐經驗分享之ORM的思考

posted @ 2017-07-31 08:29 「圣杰」閱讀(6525) 評論(11) 收藏舉報

刷新頁面返回頂部

『___知多少』

一名尋求機會努力破局的架構師