領域邏輯組織可以分為三種主要的模式：事務指令碼(transaction script)、領域模型(domain model)和表模組(table module)」
事務指令碼 transaction script
使用過程來組織業務邏輯，每個過程處理來自表現層的單個請求。大多數應用都可以被看作是一系列事務。乙個事務可能將某種資訊看作是以特定方式組織的，然後另一事務則會改變它。在客戶系統和伺服器系統這間的每次互動都包含一定數量的邏輯。它可能如顯示資料庫中的資訊那般簡單。蛤在其他一些情況下，它可能涉及許多校驗和計算的步驟。事務指令碼將所有這些邏輯組成成單個過程，在過程中直接呼叫資料庫，或者只通過乙個簡單的資料庫封裝器。每個事務都有自己的事務指令碼，儘管事務間的公共子任務可以被分解成多個子程式。
事務指令碼組織成類的方法
將數個事務指令碼放在乙個類中，每個類圍繞乙個主題將相關的事務指令碼組織在一起。(最常用)
每乙個事務指令碼對應乙個類，此時需使用命令(command)模式。使用時機
事務指令碼勝在簡單。對於只有少量邏輯的應用程式來說，使用這一模式非常自然，無論在效能上還是理解上都不會帶來太大開銷。
當業務邏輯越來越複雜時，該模式就會越來越難以保持良好的設計。它特有的問題是事務之間的冗餘**。
領域模型 domain model)
合併了行為和資料的領域的物件模型。在應用程式中使用領域模型需要建立乙個完整的由物件組成的層，來對目標業務領域建模。 你會發現其中有的物件模擬業務活動中的資料，有的物件捕捉業務使用的規則。資料和處理一般整合在一起，從而使得資料和資料之上的操作緊密聚合。
物件導向的領域模型通常看起來與資料庫模型類似，但仍有許多不同之處。領域模型混合資料和處理過程，擁有多值和複雜的的關聯網，並且使用繼承。
領域模型衍生出兩種風格。簡單領域模型看起來與資料庫設計很類似，這種設計中幾乎每乙個資料庫表都與乙個領域物件對應。而複雜領域模型則與資料庫 設計不同，它使用繼承、策略和其他設計模式，是一張由互聯的細粒度物件組成的複雜網路，複雜的領域模型更適合於複雜的邏輯，但它於資料庫的對映比較 困難。
由於業務行為是經常變化的。因此易於修改、建造和測試對領域層來說十分重要。因而，領域模型與系統中的其他層之間的耦合度應達到最小。許多的分層 模式，它們的主導思想就是領域模型與系統中其他部分間保持盡可能小的依賴
使用時機
何時使用這一模型完全取決於系統中的行為複雜程度。如果你的業務規則複雜多變，涉及檢驗、計算、衍生，你就應該利用物件模型進行處理， 反之，如果你只有一些簡單的判空值和少量的求和計算，事務指令碼是乙個更佳的選擇。
影響選擇的因素之一是開發小組靈活運用領域物件的程度。學會如何使用領域模型是極為重要的，故而出現了許多」理論體系遷移?方面的文章，它們都是關於 物件使用的。要熟悉領域模型需要實踐和訓練，但是一旦掌握了它，我發現處理解決最簡單的問題外，很少會有人再使用事務指令碼。
使用領域模型時，你可能會考慮設立乙個服務層，以便給領域模型乙個更清晰的api。
表模組 table module
表模組以乙個類對應資料庫中的乙個表來組織領域邏輯，而且使用單一的類例項來包含將對資料進行的程式種操作程式。
使用時機
最常使用這一模式的場合是在microsoft的com設計方案中。在com(及.net)中，記錄集是應用程式的主要資料倉儲。ado 庫提供了良好的機制，可供你以記錄集的方式來 訪問關聯式資料庫中的資料。
領域邏輯的組織模式
c 領域邏輯組織可以分為三種主要的模式 事務指令碼 transaction script 領域模型 domain model 和表模組 table module 事務指令碼 transaction script 使用過程來組織業務邏輯，每個過程處理來自表現層的單個請求。大多數應用都可以被看作是一系列...
領域驅動系列 三種領域邏輯組織模式的本質
企業應用架構模式中明確提出了三種領域邏輯組織模式 事務指令碼 領域模型和表模組。不少人看的雲裡霧裡的，不少人說的似懂非懂的，主要原因是沒有從專案的級別的分析和設計經驗，只有單個專案模組的開發經驗的人很難理解到位。事務指令碼的理解其實最簡單，但是很多人說不清，覺得比領域模型還難理解，也對應不到 但這只...
讀《企業應用架構模式》4 關於組織領域邏輯
關於領域邏輯的組織主要講了 貫穿領域層裡的某些東西 1.事務指令碼 指令碼 顧名思義就是 sql語句 當然如果我們運算元據庫，必然要在乙個事務中，這樣就出會事務指令碼的概念，估計市場是小的應用都是這樣的組織的，記得8年前做廣電專案的時候，就是這用他來組織 的，如果大家看過bbs 大部分也是應用這種模...