本系列的第一篇博文拋磚引玉，大談領域驅動設計的優勢，這裏筆者還是希望以客觀的態度，談談領域驅動設計的缺點及其不適合使用的場景，以讓讀者可以有選擇性的使用領域驅動設計。

我們知道，沒有最好，只有最合適，設計也是一樣。因此，所謂設計，就是以你和你的團隊的知識、經驗和智慧，全面充分的考慮各種內外因素後，在你們的設計方案中作出合理的選擇的過程。而這些影響你們選擇的因素主要有：

• 技術框架的特征和約束（如果你的項目決定使用C語言進行開發，那麽首先在設計方法上，就需要使用面向過程而非面向對象的設計方法）。

• 時間的壓力和約束（你永遠不可能告訴你的老板，給我10年時間，我和我的團隊將為你設計出世界上最優秀的軟件）。

• 你的團隊的能力、經驗、性格、價值觀等因素的約束（你不能期望一個長期從事遺留系統維護項目或大部分成員是缺乏經驗的高校畢業生的團隊能很好的按照你的設計意圖去實現你的高度抽象的優秀設計，同時你也別指望一幫家裏經濟條件不錯，本著過來熬時間的家夥會樂意與你一起刻苦鉆研、精益求精）。

• 你的系統的特征（如果你想把一個足夠簡單而且在可以預計的將來都不存在很大規模的需求變更的系統設計得很復雜，很精妙，具有很好的擴展性，但要為此付出巨大的時間、人力成本，這顯然是一種不理智的過度設計（Over design））。

• 其他外在因素的約束（你的項目需要參與投標，你必須壓縮人力、時間等以讓你的項目成本成為巨大的競爭資本）。

當然，上述的考慮因素站在比較高的角度，通常是項目經理、架構師需要考慮的問題，但這當中你應該會得到一些啟發。回到我們的主題，我們首先看看，領域驅動設計相對於傳統的面向過程式的設計，有什麽缺點：

• 復雜化：面向過程思維之所以一直很受歡迎，是因為它很直觀，非常符合大部分人的思維習慣，大部分人拿到一個問題，通常都是會很直觀的想第一步做什麽、第二步做什麽，如果怎樣，應該怎樣，否則怎樣……，可以說，任何水平的程序員，都能很好的使用面向過程的方法進行設計和開發。同時，由於我們教育水平的落後和整體IT環境的制約，可以這樣說，真正掌握面向對象思維和設計方法的程序員的比例非常低（雖然絕大部分都使用面向對象的語言和工具），而本身面向對象思維要求人有很好的抽象思維能力，因為你需要把一個復雜的系統一層層的抽象為簡單的部分，需要把現實世界的事物（有些是可見的，但有些是不可見）合理的抽象為計算機世界的不同元素。這些都不是一些很容易做的事情，要做得好，就更難。

• 團隊的抗拒：如果你的團隊（很大可能）大部分人都習慣於用很直觀的面向過程的方式進行設計和開發，你需要推動你的團隊轉換思維來采用面向對象的方式進行領域驅動設計，通常會遭到多數人的抗拒。因為人都是有惰性的，他們習慣安於現狀，而改變是痛苦的，他們要付出額外的努力，需要進行學習，但以筆者的經驗，相當一部分程序員，特別是有一定工作年限的程序員，他們從事IT工作都只是為了獲得一份不錯的報酬，因此他們的學習動力非常有限，而且，他們都相當自負，被說服的難度比較大。

• 管理、開發和維護的成本高：復雜度更高，意味著你需要花更多的時間進行設計，同時需要花出額外的時間進行必要的培訓，而且需要有更完善的文檔（設計文檔，API文檔，培訓文檔等）。領域驅動設計的抽象程度比較高，因此必需有良好的文檔，否則，隨著項目的不斷叠代、升級和維護，它很容易因為後來者的誤解而慢慢回歸面向過程的設計，甚至會變得“四不象”，領域驅動設計的成本優勢是隨著時間的推移慢慢體現的（見下圖），如果出現這種情況，所有前面付出的努力都會付諸東流。

系統的初始階段，領域驅動設計需要付出更大的成本，但隨著時間的推移，領域驅動設計的成本效益優勢會逐步顯現

• 性能比較低：使用純面向對象的方式進行領域驅動設計的程序，其系統開銷通常要比面向過程設計的程序高，從而性能相對較低（關於具體的例子，後續的博文會提及）。

那麽，假設我們在時間、團隊能力及各種資源都允許的情況下，是否就可以麻木的全盤使用領域驅動設計呢？正如本博文的標題一樣，答案是否定的，我們需要有選擇性的使用。讓我們來看看一些指導性原則：

• 使用領域驅動設計，並不代表整個系統的方方面面都必須遵從領域驅動設計的原則，需要根據實際情況，讓適合的部分使用領域驅動設計，讓不適合的部分使用面向過程的設計。

• 對於那些業務規則非常簡單，通常只有增、刪、改、查的簡單操作，而且也不大可能發生大規模需求變更的模塊，可以讓業務實體成為一個“貧血模型”，例如一些基礎數據：系統參數、商品類型、國家、地址信息（註：對於這點，本人持保留態度，因為這些業務雖然非常簡單，但既然選擇了領取驅動設計，即使把這些業務實體設計為“充血模型”，即把極其簡單的業務邏輯也封裝在業務實體中，也並不比使用“貧血模型”成本高，而它卻帶來了統一設計風格的好處）。

• 對於查詢操作，特別是復雜的查詢操作，出於性能的考慮，可以用結構化查詢邏輯一次性完成，並把這些邏輯封裝在Repository（即技術上的DAO）中（這方面的具體例子，後面關於“查詢通道”和“領域對象倉庫”的博文會更具體的闡述）。我們可以看到，對於一些業務視圖，以及報表模塊，很明顯不適合使用面向對象的方式設計，因為這些“視圖”和“報表”，本質上就不是業務實體。

• 同樣出於性能的考慮，在業務實體的實現邏輯中，某些操作不適合過度偏執的使用面向對象方式。例如，在“訂單”的“新增訂單明細”（order.addOrderItem(orderItem)）中，如果業務邏輯規定一張訂單中包含優惠商品的明細數目不能超過20條，使用面向對象的方式，就需要把訂單中的所有訂單明細全部加載，然後逐個明細判斷其對應的商品是否優惠商品，再統計出優惠商品的數目，這樣很明顯是低效率和高開銷的，這裏只需要使用Repository提供的一個統計方法，用一個結構化查詢邏輯返回統計結果即可，而這就是非面向對象的方式。

本博文給有誌於領域驅動設計的讀者潑了一下冷水，提出一些“反模式”（Bitter），是為了讓讀者冷靜一下，在領域驅動設計過程中作出更靈活和更合理的選擇。關於這方面的論述，筆者在這裏淺嘗則止，限於水平、經驗和表達能力，不敢胡亂賣弄，建議讀者可以參考閱讀Martin Fowler的《Patterns of Enterprise Application Architecture》一書的相關觀點。

領域驅動設計系列文章（3）——有選擇性的使用領域驅動設計