“領域邏輯組織可以分為三種主要的模式：事務指令碼（Transaction Script）、領域模型（Domain Model）和表模組（Table Module）”
事務指令碼 Transaction Script
使用過程來組織業務邏輯，每個過程處理來自表現層的單個請求。大多數應用都可以被看作是一系列事務。一個事務可能將某種資訊看作是以特定方式組織的，然後另一事務則會改變它。在客戶系統和伺服器系統這間的每次互動都包含一定數量的邏輯。它可能如顯示資料庫中的資訊那般簡單。蛤在其他一些情況下，它可能涉及許多校驗和計算的步驟。事務指令碼將所有這些邏輯組成成單個過程，在過程中直接呼叫資料庫，或者只通過一個簡單的資料庫封裝器。每個事務都有自己的事務指令碼，儘管事務間的公共子任務可以被分解成多個子程式。
事務指令碼組織成類的方法
-
將數個事務指令碼放在一個類中，每個類圍繞一個主題將相關的事務指令碼組織在一起。（最常用）
-
每一個事務指令碼對應一個類，此時需使用命令（Command）模式。
使用時機
事務指令碼勝在簡單。 對於只有少量邏輯的應用程式來說，使用這一模式非常自然，無論在效能上還是理解上都不會帶來太大開銷。
當業務邏輯越來越複雜時，該模式就會越來越難以保持良好的設計。它特有的問題是事務之間的冗餘程式碼。
領域模型 Domain Model)
合併了行為和資料的領域的物件模型。在應用程式中使用領域模型需要建立一個完整的由物件組成的層，來對目標業務領域建模。 你會發現其中有的物件模擬業務活動中的資料，有的物件捕捉業務使用的規則。資料和處理一般整合在一起，從而使得資料和資料之上的操作緊密聚合。
物件導向的領域模型通常看起來與資料庫模型類似，但仍有許多不同之處。領域模型混合資料和處理過程，擁有多值和複雜的的關聯網，並且使用繼承。
領域模型衍生出兩種風格。簡單領域模型看起來與資料庫設計很類似，這種設計中幾乎每一個資料庫表都與一個領域物件對應。而複雜領域模型則與資料庫 設計不同，它使用繼承、策略和其他設計模式，是一張由互聯的細粒度物件組成的複雜網路，複雜的領域模型更適合於複雜的邏輯，但它於資料庫的對映比較 困難。
由於業務行為是經常變化的。因此易於修改、建造和測試對領域層來說十分重要。因而，領域模型與系統中的其他層之間的耦合度應達到最小。許多的分層 模式，它們的主導思想就是領域模型與系統中其他部分間保持儘可能小的依賴
使用時機
何時使用這一模型完全取決於系統中的行為複雜程度。如果你的業務規則複雜多變，涉及檢驗、計算、衍生，你就應該利用物件模型進行處理， 反之，如果你只有一些簡單的判空值和少量的求和計算，事務指令碼是一個更佳的選擇。
影響選擇的因素之一是開發小組靈活運用領域物件的程度。學會如何使用領域模型是極為重要的，故而出現了許多”理論體系遷移？"方面的文章，它們都是關於 物件使用的。要熟悉領域模型需要實踐和訓練，但是一旦掌握了它，我發現處理解決最簡單的問題外，很少會有人再使用事務指令碼。
使用領域模型時，你可能會考慮設立一個服務層，以便給領域模型一個更清晰的API。
表模組 Table Module
表模組以一個類對應資料庫中的一個表來組織領域邏輯，而且使用單一的類例項來包含將對資料進行的程式種操作程式。
使用時機
最常使用這一模式的場合是在Microsoft的COM設計方案中。在COM（及.net)中，記錄集是應用程式的主要資料倉儲。ADO 庫提供了良好的機制，可供你以記錄集的方式來 存取關聯式資料庫中的資料。
程式碼示例：https://github.com/tianyaxiang/ApplicationArchitecture
本文首發於個人微信公眾號：webguan ；歡迎您的關注
