作者：百度有啊實驗室
來源：http://www.youalab.com/?p=458
前言
相信很多人都有類似的經歷：隨着業務越來越多， 系統的越來越複雜， 我們都會感覺我們的代碼越來越難看， 重複代碼越來越多， 越來越難以維護。 恩， 這確實是個問題， 但有沒有可能解決的辦法？ 老實說， 確實很難， 但不是完全沒有可能， 或者說有改善的可能。 最近就關於這方面進行了一些學習和考慮， 以純理論的方式總結了一下， 希望能對對這方面有興趣的同學有所幫助。
很多面嚮應用的系統是以數據爲中心的， 在這些系統中， 以數據庫存儲數據； 業務邏輯代碼則根據需求圍繞着數據庫中存儲的數據來組織邏輯；以購買商品的系統爲例， 商品數據， 交易數據和用戶數據是系統中的核心數據， 絕大多數業務代碼則是根據需求來倒騰這些數據。這個非常符合那個關於程序的定義： 程序 = 數據 + 行爲； 在這裏， 數據是數據庫中的數據， 行爲則對應業務邏輯。
對於所構建的系統， 我們自然希望可擴展性好， 可維護性；這是一個非常有挑戰性對的事情， 大型的應用尤其如此； 能否真的做就在很大程度取決於邏輯的組織方式。 這篇文章大體介紹以數據庫爲中心的應用中的三個典型的業務邏輯組織方式。
邏輯組織方式
事務腳本方式
這裏的事務與數據庫術語事務有所區別， 這裏的事務更多的指一次業務交互。
在應用系統中， 大多數業務邏輯可以看做一系列子任務的集合； 比如用戶購買一個商品時， 可以大體分成幾步：
- 先根據商品的信息到數據庫中查詢是否有可銷售的商品存在；
- 有的話， 添加一個用戶購買商品的購買記錄；
- 然後把商品數量減少；
- 其他事情， 比如發郵件通知用戶等。
以事務腳本方式組織代碼時， 業務邏輯組織上沒有層次之分， 在實現一個具體業務時， 根據其業務的需要從前到後進行一系列的事務調用； 就購買商品爲例， 先從數據庫中查詢商品數量， 然後判斷是否足夠， 足夠的話添加用戶購買商品的記錄， 然後操作數據庫減少商品。這種方式有個明顯的特點， 一個事務腳本實現以一個用例或者或者一個功能。這個方式優點很明顯， 簡單，直觀， 易學易用，開發速度快；這些容易理解， 因爲這些寫代碼的方式與直觀的思維方式類似， 在實際中， 很多系統都是這樣實現的；尤其那些快速開發系統； 但是抽象度低， 容易導致重複代碼多，與其他系統的耦合程度高， 維護麻煩，尤其是對於複雜的系統來說。 舉個例子來說，購買商品購買這個功能，桌面版提供了之後，手機版的也需要實現， 由於手機版與桌面版是兩個不同的用例， 如果用事務腳本來組織代碼的話， 很自然的就會出現類似的代碼出現在了不同的地方的情況。 一個很明顯的優化是封裝成函數， 但是封裝成函數這個事情的模塊化程度低， 在業務複雜的情況下， 對業務邏輯的有效管理和維護是一個挑戰。
事務腳本這種方式適用於相對簡單的業務邏輯環境，而且在現實中， 很多業務本身就是簡單的， 這種方式可以在開發高效， 運行高效的前提下工作的很好； 另外對於快速開發環境中也非常適用。 但是當業務邏輯複雜， 而且上線後維護期很長或維護量很大的系統來說，可能不是一種很好的方式。
表模塊方式
在事務腳本方式當中，很容易導致:
- 相同或者類似的代碼重複出現;
- 相關邏輯分佈在多個地方。對於前一個問題， 可以通過把相同或者相似邏輯封裝成函數來改進， 第二個問題通過流程或規範可以得到控制。 但是， 還是會在業務複雜的情況下對業務邏輯的有效管理和維護是一個挑戰 因爲缺乏一種有效的編碼的機制來控制這樣的問題。
表模塊組織方可以從機制上提供一個相對好的解決辦法， 其大概思路是，把與一個或者多個數據庫表(或者視圖)有關的邏輯組織成一個類， 把對與這個表有關的邏輯組織成這個類的方法。以上面那個購買商品爲例， 查詢商品是否足夠可能是一個單獨的方法， 修改商品數量是一個單獨的方法；購買商品是一個方法，所完成的事情就是把前面兩個方法組織起來。 一旦有了這個邏輯， 只要是需要用到購買商品邏輯的地方， 直接調用這個購買商品的方法就可以了； 除了這個購買商品之外， 其他與商品有關邏輯都組織在這個類裏面，避免了與商品有關的邏輯分佈到多個地方。
除了提供一個代碼組織的方式外，這種組織方式還有一些其他的好處：不需要數據庫表就直接可以測試，也便於打樁測試； 與很多數語言提供的數據庫操作API配合使用方便， 很多數據庫操作API返回的結果都市記錄集的方式， 尤其以微軟提供的相關API爲典型代表， .NET提供的Dataset更是功能強大。實際上， 微軟提供的開發平臺倡導的就是以表模塊方式組織邏輯， 並提供了各種便利的開發工具和API； 在管理代碼的有效性和複雜度上有比較好的平衡，他比前面的事務腳本方式相對繁瑣點， 比後面好提到的領域模型方式簡單很多。
領域模型
領域模型方式組織代碼就是OO的編程思想， 把領域邏輯對象化， 從而達到在複雜的業務邏輯是有好的可擴展性和可維護性。表模塊組織方式在管理代碼的有效性和複雜度上有比較好的平衡， 但是在其提供的抽象機制畢竟有限； 在管理複雜的業務邏輯方面有些不給力。比如， 對於不同類型的商品， 其購買邏輯可能不一樣；這時候， 面向對編碼的威力會就能比較好的發揮了， 商品這個例子中， 購買時的行爲可能不一樣， 利用多態機制， 對調用者來說可能是透明的。
領域模型這種方式與表模型的方式的區別在於OO的力度不一樣； 表模型以表爲單位來組織， 領域模型可能則以表裏面的記錄爲單位來組織的， 因此代碼中， 一個表只有一個類實例， 而領域模型則會針對一條記錄有個對象。
模型這種方式的優點是便於有效的管理複雜性和可擴展性， 對於複雜的業務邏輯以及那種維護週期很長的系統來說比較適用； 但其缺點也很明： OO建模複雜，開發週期相對會長些；學習成本高， 尤其對於新團隊來說； 同樣， 如果代碼組織不好， 也會出現其他方式中出現的類似問題， 如代碼重複等。
小結
三種不同的邏輯組織方式各有特點， 適用於不同的場合， 可以根據實際情況選擇， 一般來說， 簡單應用， 要求快速開發快， 維護週期短的可以考慮事務腳本方式； 業務邏輯複雜， 維護週期長時， 在開發人員技能滿足的條件下可以考慮領域模型； 在這個兩個中間的情況可以考慮表模塊方式， 尤其是在微軟的平臺上。 在實際中，由於實際業務的複雜性， 很多時候以一種單一的方式組織還不夠， 可能幾個方式綜合起來運用。 比如， 把核心業務按領域對象的方式組織， 之上再以事務腳本來組織多變的應用業務。