領域邏輯組織能夠分爲三種主要的模式：事務腳本(Transaction Script)、領域模型(Domain Model)和表模塊(Table Module)。數據庫
咱們用得最多就是事務腳本方式（像微軟的Petshop4.0,不少國內的三層結構代碼生成工具生成的系統，並且這種方式不少公司，不少企業級的項目都在用，還有一些框架引導你用這種方式實現)。這種方式最大的特色就是：簡單實用。設計模式
-
事務腳本
使用流程來組織業務邏輯，每一個流程處理來自表示層的單個請求。大多數應用程序可被視爲一系列事務。交易能夠將某種信息視爲以特定方式組織，而後另外一種交易將改變它。客戶端系統和服務器系統之間的每次交互都包含必定量的邏輯。它可能與在數據庫中顯示信息同樣簡單。在其餘狀況下，它可能涉及校驗和計算中的許多步驟。事務腳本將全部這些邏輯組合到一個進程中，直接在進程中調用數據庫，或者只傳遞一個簡單的數據庫包裝器。每一個事務都有本身的事務腳本，儘管事務之間的常見子任務能夠分解爲多個子例程。服務器
事務腳本組織成類網絡
將多個事務腳本放在一個類中，每一個類圍繞一個主題組織相關的事務腳本。 （最常被使用）架構
每一個事務腳本對應一個類，您須要使用命令模式。框架
什麼時候使用數據庫設計
腳本獲勝很簡單。對於具備少許邏輯的應用程序，使用此模式是很天然的，而且在性能或理解方面沒有任何開銷。工具
隨着業務邏輯變得愈來愈複雜，維護良好設計變得愈來愈困難。它的獨特問題是交易之間的冗餘代碼。post
-
領域模型
一種對象模型，它結合了行爲和數據的字段。在應用程序中使用域模型須要構建完整的對象層以對目標業務域建模。您會發現某些對象模擬業務活動中的數據，而某些對象捕獲業務使用的規則。一般集成數據和處理，以便對數據和數據的操做進行緊密聚合。性能
面向對象的域模型一般看起來相似於數據庫模型，但仍然存在許多差別。域模型混合了數據和流程，具備多值和複雜的關聯，並使用繼承。
域模型派生出兩種樣式。簡單域模型看起來很是相似於數據庫設計，其中幾乎每一個數據庫表都對應於域對象。複雜域模型與數據庫設計不一樣。它使用繼承，策略和其餘設計模式。它是由互連的細粒度對象組成的複雜網絡。複雜域模型更適合複雜邏輯，但它在數據庫中。映射很困難。
由於商業行爲在不斷變化。所以，很容易修改，構建和測試域層。所以，域模型與系統中其餘層之間的耦合程度應該是最小的。許多分層模型，它們的主導思想是使域模型在系統的其他部分之間保持儘量小。
什麼時候使用
什麼時候使用此模型徹底取決於系統中行爲的複雜性。若是業務規則複雜且可變，涉及檢查，計算和派生，則應使用對象模型進行處理。相反，若是您只有一些簡單的空值和少許的求和計算，那麼事務腳本就更好了。選擇。
影響選擇的因素之一是開發團隊能夠靈活使用域對象的程度。學習如何使用領域模型是很是重要的，因此有不少關於「理論系統的遷移？」的文章，這些都是關於對象的使用。熟悉領域模型須要實踐和培訓，可是一旦掌握了它，我發現除了解決最簡單的問題以外，不多有人使用事務腳本。
使用域模型時，您能夠考慮設置服務層，以便爲域模型提供更清晰的API。
-
表模塊
表模塊將域邏輯組織在與數據庫中的表對應的類中，並使用單個類實例來包含將執行數據的程序。
什麼時候使用
此模式最多見的用途是Microsoft的COM設計。在COM（和.net）中，記錄集是應用程序的主要數據倉庫。 ADO庫提供了一種很好的機制，能夠將關係數據庫中的數據做爲記錄集進行訪問。
| 實現方式 |
優勢 |
缺點 |
備註 |
| 事務腳本 |
|
|
像Petshop4.0、國內不少三層架構代碼生成工具生成的系統以及現今國內絕大部分企業級系統(本人估計)都採用這種方式 |
| 領域模型 |
1． 採面向對象方法直接對系統的問題域進行分析或建模，領域模型直觀地反映現實世界，可以更好用面嚮對象語言模型轉換，是一種純OO模型 2． 可以解決很複雜的業務邏輯 3． 能夠有效地利用面向對象的特性（抽象，封裝，繼承、多態等）與相關技術（如設計模式，重構等），以提升系統的可擴展性與複用性。 |
|
如今不少企業級應用項目開始採用此方式，這主要得益於ORM框架不斷成熟，以及模式運動，同時一些設計原則也比較好解決相應問題。 請參看參考書目的： 十一、1三、1六、六、二、5
|
| 表模塊 |
1． 適合於系統業務較直觀，CRUD操做比較集中 2． 若是支持平臺中有比較好工具集支持(如：Ado.Net，數據控件之類)，開發速度快，效率高 |
1．當業務並不是CRUD集中型操做，特別是領域模型和數據庫表模型差別較大時，難度很是大，所以不適合業務複雜的系統 |
在Microsoft .Net平臺有不少工具集支持，有時候你甚至不需寫一行代碼就能夠實現CRUD操做 |