領域驅(qū)動設計系列文章（3）——有選擇性的使用領域驅(qū)動設計
本系列的第一篇博文拋磚引玉，大談領域驅(qū)動設計的優(yōu)勢，這里筆者還是希望以客觀的態(tài)度，談談領域驅(qū)動設計的缺點及其不適合使用的場景，以讓讀者可以有選擇性的使用領域驅(qū)動設計。
我們知道，沒有最好，只有最合適，設計也是一樣。因此，所謂設計，就是以你和你的團隊的知識、經(jīng)驗和智慧，全面充分的考慮各種內(nèi)外因素后，在你們的設計方案中作出合理的選擇的過程。而這些影響你們選擇的因素主要有：
-
技術框架的特征和約束（如果你的項目決定使用C語言進行開發(fā)，那么首先在設計方法上，就需要使用面向過程而非面向?qū)ο蟮脑O計方法）。
-
時間的壓力和約束（你永遠不可能告訴你的老板，給我10年時間，我和我的團隊將為你設計出世界上最優(yōu)秀的軟件）。
- 你的團隊的能力、經(jīng)驗、性格、價值觀等因素的約束（你不能期望一個長期從事遺留系統(tǒng)維護項目或大部分成員是缺乏經(jīng)驗的高校畢業(yè)生的團隊能很好的按照你的設計意圖去實現(xiàn)你的高度抽象的優(yōu)秀設計，同時你也別指望一幫家里經(jīng)濟條件不錯，本著過來熬時間的家伙會樂意與你一起刻苦鉆研、精益求精）。
-
你的系統(tǒng)的特征（如果你想把一個足夠簡單而且在可以預計的將來都不存在很大規(guī)模的需求變更的系統(tǒng)設計得很復雜，很精妙，具有很好的擴展性，但要為此付出巨大的時間、人力成本，這顯然是一種不理智的過度設計（Over design））。
- 其他外在因素的約束（你的項目需要參與投標，你必須壓縮人力、時間等以讓你的項目成本成為巨大的競爭資本）。
當然，上述的考慮因素站在比較高的角度，通常是項目經(jīng)理、架構師需要考慮的問題，但這當中你應該會得到一些啟發(fā)。回到我們的主題，我們首先看看，領域驅(qū)動設計相對于傳統(tǒng)的面向過程式的設計，有什么缺點：
- 復雜化：面向過程思維之所以一直很受歡迎，是因為它很直觀，非常符合大部分人的思維習慣，大部分人拿到一個問題，通常都是會很直觀的想第一步做什么、第二步做什么，如果怎樣，應該怎樣，否則怎樣……，可以說，任何水平的程序員，都能很好的使用面向過程的方法進行設計和開發(fā)。同時，由于我們教育水平的落后和整體IT環(huán)境的制約，可以這樣說，真正掌握面向?qū)ο笏季S和設計方法的程序員的比例非常低（雖然絕大部分都使用面向?qū)ο蟮恼Z言和工具），而本身面向?qū)ο笏季S要求人有很好的抽象思維能力，因為你需要把一個復雜的系統(tǒng)一層層的抽象為簡單的部分，需要把現(xiàn)實世界的事物（有些是可見的，但有些是不可見）合理的抽象為計算機世界的不同元素。這些都不是一些很容易做的事情，要做得好，就更難。
- 團隊的抗拒：如果你的團隊（很大可能）大部分人都習慣于用很直觀的面向過程的方式進行設計和開發(fā)，你需要推動你的團隊轉換思維來采用面向?qū)ο蟮姆绞竭M行領域驅(qū)動設計，通常會遭到多數(shù)人的抗拒。因為人都是有惰性的，他們習慣安于現(xiàn)狀，而改變是痛苦的，他們要付出額外的努力，需要進行學習，但以筆者的經(jīng)驗，相當一部分程序員，特別是有一定工作年限的程序員，他們從事IT工作都只是為了獲得一份不錯的報酬，因此他們的學習動力非常有限，而且，他們都相當自負，被說服的難度比較大。
- 管理、開發(fā)和維護的成本高：復雜度更高，意味著你需要花更多的時間進行設計，同時需要花出額外的時間進行必要的培訓，而且需要有更完善的文檔（設計文檔，API文檔，培訓文檔等）。領域驅(qū)動設計的抽象程度比較高，因此必需有良好的文檔，否則，隨著項目的不斷迭代、升級和維護，它很容易因為后來者的誤解而慢慢回歸面向過程的設計，甚至會變得“四不象”，領域驅(qū)動設計的成本優(yōu)勢是隨著時間的推移慢慢體現(xiàn)的（見下圖），如果出現(xiàn)這種情況，所有前面付出的努力都會付諸東流。
系統(tǒng)的初始階段，領域驅(qū)動設計需要付出更大的成本，但隨著時間的推移，領域驅(qū)動設計的成本效益優(yōu)勢會逐步顯現(xiàn)
- 性能比較低：使用純面向?qū)ο蟮姆绞竭M行領域驅(qū)動設計的程序，其系統(tǒng)開銷通常要比面向過程設計的程序高，從而性能相對較低（關于具體的例子，后續(xù)的博文會提及）。
那么，假設我們在時間、團隊能力及各種資源都允許的情況下，是否就可以麻木的全盤使用領域驅(qū)動設計呢？正如本博文的標題一樣，答案是否定的，我們需要有選擇性的使用。讓我們來看看一些指導性原則：
- 使用領域驅(qū)動設計，并不代表整個系統(tǒng)的方方面面都必須遵從領域驅(qū)動設計的原則，需要根據(jù)實際情況，讓適合的部分使用領域驅(qū)動設計，讓不適合的部分使用面向過程的設計。
- 對于那些業(yè)務規(guī)則非常簡單，通常只有增、刪、改、查的簡單操作，而且也不大可能發(fā)生大規(guī)模需求變更的模塊，可以讓業(yè)務實體成為一個“貧血模型”，例如一些基礎數(shù)據(jù)：系統(tǒng)參數(shù)、商品類型、國家、地址信息（注：對于這點，本人持保留態(tài)度，因為這些業(yè)務雖然非常簡單，但既然選擇了領取驅(qū)動設計，即使把這些業(yè)務實體設計為“充血模型”，即把極其簡單的業(yè)務邏輯也封裝在業(yè)務實體中，也并不比使用“貧血模型”成本高，而它卻帶來了統(tǒng)一設計風格的好處）。
- 對于查詢操作，特別是復雜的查詢操作，出于性能的考慮，可以用結構化查詢邏輯一次性完成，并把這些邏輯封裝在Repository（即技術上的DAO）中（這方面的具體例子，后面關于“查詢通道”和“領域?qū)ο髠}庫”的博文會更具體的闡述）。我們可以看到，對于一些業(yè)務視圖，以及報表模塊，很明顯不適合使用面向?qū)ο蟮姆绞皆O計，因為這些“視圖”和“報表”，本質(zhì)上就不是業(yè)務實體。
- 同樣出于性能的考慮，在業(yè)務實體的實現(xiàn)邏輯中，某些操作不適合過度偏執(zhí)的使用面向?qū)ο蠓绞健＠纾?#8220;訂單”的“新增訂單明細”（order.addOrderItem(orderItem)）中，如果業(yè)務邏輯規(guī)定一張訂單中包含優(yōu)惠商品的明細數(shù)目不能超過20條，使用面向?qū)ο蟮姆绞剑托枰延唵沃械乃杏唵蚊骷毴考虞d，然后逐個明細判斷其對應的商品是否優(yōu)惠商品，再統(tǒng)計出優(yōu)惠商品的數(shù)目，這樣很明顯是低效率和高開銷的，這里只需要使用Repository提供的一個統(tǒng)計方法，用一個結構化查詢邏輯返回統(tǒng)計結果即可，而這就是非面向?qū)ο蟮姆绞健?/span>
本博文給有志于領域驅(qū)動設計的讀者潑了一下冷水，提出一些“反模式”（Bitter），是為了讓讀者冷靜一下，在領域驅(qū)動設計過程中作出更靈活和更合理的選擇。關于這方面的論述，筆者在這里淺嘗則止，限于水平、經(jīng)驗和表達能力，不敢胡亂賣弄，建議讀者可以參考閱讀Martin Fowler的《Patterns of Enterprise Application Architecture》一書的相關觀點。