在業務層的模式上有幾種選擇。首先是過程式模式，在面向對象開發興起之前，業務邏輯只不過是一系列過程的集合，每個集合都用來處理來自於表現層的一個請求。因此好的設計都在於更好的去組織這些過程，減少代碼和流程的冗餘。基於對象的模式抽象程度越高，與數據模型的差距也會越大，因此若想創建一個領域驅動的對象模型，一般應該從領域着眼，而不是從數據庫結構開始。領域驅動的設計一定會使數據庫模型和領域模型之間存在不小差異。這個模式通常叫做領域模型。
基於對象的模式在開始時代價較高，但隨着複雜性增長，其代價基本上也線性增加。換句話說，一旦你對領域模型有足夠的瞭解，無論系統的複雜性如何，你都可以使用領域模型模式。在複雜性度量上，複雜性分爲兩方面，第一種是天生的，不可避免，無法協調需求本身，這類複雜性可以通過一些方法或多或少降低，不過不可能完全抹除，必須直接面對。第二種是來自於引入的複雜，這個來自於不同項目干係人意見的不協調，負面效果就是將團隊引向錯誤的方向，錯誤的方向則會讓抽象設計包含不必要或非功能性的功能，將軟件逼上絕路。
需求的數量可以用來粗略判斷系統的複雜性，認識到複雜性比解釋如何找到複雜性更加簡單。
1 事務腳本模式
事務腳本模式的關注點在於用戶通過表現層所能執行的操作，併爲每個操作編寫一個專門的方法，這個方法就叫做一個事務腳本。
“事務”在這裏指一個需要執行的業務流程。“腳本”表示在業務流程上執行的一系列操作。
1.1 何時使用？
事務腳本易於理解和解釋。每個必須的用戶操作都在一個事務中開始，直至結束。不過數據訪問通常被封裝在另一個組件中，並不屬於腳本的一部分。
事務腳本給出的模型中的邏輯均是使用IF、WHILE和FOR等語言元素表述的。向現有用戶操作中添加新功能就意味着添加一個新分支或在現有代碼的某處添加一個新的子程序。
事務腳本適合應用於那些業務邏輯非常簡明直白，且最好不大可能改變的簡單場景中。
1.2 優勢
事務腳本是一個簡單的過程式模型，它以邏輯事務的集合的形式來表現應用程序的邏輯。使用過程式方法並不意味着需要編寫大段、不可拆分的代碼。一個高層次的事務可以被拆分成更簡單、可重用的子程序或層。最常見的一個層就使持久層，其中你會發現一些小的、用來處理數據訪問以及相關事務的組件。下圖所示爲基於事務腳本的系統的大體結構。
1.3 劣勢
簡單是事務腳本模式最值得一提的優勢，但是事務腳本有造成代碼重複的潛質。所有實現了事務腳本的類型都可以看做是業務組件，每個業務組件都可以有一個或多個事務。比較流行的設計方式是將各個事務腳本分組，然後讓每一組成爲一個業務組件，這樣每一組中的事務腳本在邏輯上都是相關的。另一種做法是將每個事務腳本用單獨的類封裝起來，這樣每個業務組件都僅包含一個方法，換句話說，這裏的業務組件就變成了一堆命令對象。若想將事務腳本的業務組件設計成命令對象，可以釋放出一個接口，並將所有需要的參數以類型公有屬性的形式暴露出來。
2 表模式
與事務腳本相比，表模塊更有結構，表模塊作爲一個容器，將數據和行爲組合在一起。業務邏輯被拆分爲粗粒度的、表示整個數據表的組件。表模塊的粒度不會下降到數據行的程度，即表模塊類無法區分每一行數據。表模塊模式應用中，使用基於記錄集的數據結構是最常見的方式。例如Dataset、Datatable等。
對那些不需要太多抽象，且數據模型和對象模型之間沒有太大差異的場景，表模塊是個非常不錯的折衷方案。與事務腳本相比，表模塊基於一個概念模型。而不是一大批方法的鬆散集合。若系統中的表現層和數據訪問層都是基於表狀數據結構，那麼表模塊將是非常好的選擇，這時，業務層即可爲表現層提供直接可用的數據，有時甚至可以直接通過數據綁定實現。
表模塊並沒有比事務腳本複雜很多，不過若完全需要手工構造，那麼花費的時間可能比簡單的事務腳本多出很多。模式在提供了更多指導的同時，也意味着我們需要考慮更多規則，也就是編寫更多代碼。
內嵌的Dataset設計器提供Fill和GetData方法來基於整個數據表進行查詢。從概念角度講，表模塊的另一個優勢在於，無論底層數據源是什麼，對於同一些功能都會得到同樣的表模塊類。表模塊基於對象，但完全由數據庫驅動。表模塊並不適合表述複雜的衆多實體。特別是對象模型和數據模型之間有顯著差距的時候。表模塊的優勢是VS提供了強大的支持，實現起來簡單，不過考慮到這些生成的代碼類似於一個黑箱，優勢也就成了劣勢。當然，表模塊這個結構模型不一定需要和VS緊密耦合。
3 活動記錄模式
事務腳本和表模塊都是過程式模式。但是表模塊基於對象，不是一個對於基於對象業務邏輯建模模式。最終走向面向對象設計關鍵的一步是你認識到系統中的目標對象，業務邏輯和領域邏輯纔是系統的核心，它是由實體之間必須的交互組成的。
活動記錄是一種應用於相對簡單的領域模型，但仍基於對象模式。另一種更加容易理解的說法是，活動記錄基於數據表中的行，而不是表模塊那樣基於數據表。也就是說，活動記錄對數據有行級別的粒度，而表模塊關注的是整張表。活動記錄模式歸爲數據源設計模式，廣州達內而不是業務邏輯模式。活動記錄模式就是指一個封裝了數據表或視圖的一行的對象，對象中可以同時包含數據和行爲，活動記錄對象的結構應該儘可能地接近於相關聯的數據表結構。
在那些沒有服務層的應用程序中，活動記錄模式可以和事務腳本結合使用。
活動記錄模式的成功依賴於兩個因素：簡單和框架。這兩個因素緊密相關。我們最常見和熟悉的是LINQ- to - SQL。相對於簡單的邏輯來說，活動記錄非常合適。活動記錄的另一個問題是對象和數據庫表設計之間的綁定。若你不得不修改數據庫，那麼同時也要修改活動記錄對象模型以及所有相關代碼，從這個角度看，活動記錄站在了領域驅動的對立面。
4 領域模型
在設計領域邏輯時，若選用了過程式方法或活動記錄模式，那麼實際上採取的是以數據爲核心的做法。驅動業務模型設計的並不是業務本身，而是業務中使用到的數據。
從長遠看，以數據爲中心的方法並不能很好的適應規模的增加。因爲當系統的複雜性達到某個極限之後，哪怕是再添加一些新的需求，都會成爲難處理的問題。領域模型關注於系統的期待行爲以及系統正常工作所需要的數據。領域驅動設計力求將複雜性控制在一個可控（雖然仍舊很高）範圍內，選用領域驅動設計並不一定需要使用領域模型模式，不過領域模型模式是最自然的選擇。
領域模型描述了系統中涉及的實體，捕獲了實體之間的關係以及數據在其中交換的過程。領域模型此刻還並不是一個軟件，也不涉及任何軟件或實現上的概念或原則。領域模型只是一個正式的模型，用來讓技術團隊和業務團隊彼此理解並能良好交流。領域模型可以看作是活動記錄的“大哥”，領域模型完全和數據庫獨立，是一個儘可能貼近真實流程的模型。領域模型模式使系統建模非常自由靈活，無需考慮平臺和數據庫的約束。此外，領域驅動設計是一種看待設計的方式，因此技能和態度起到了重要的作用。
在領域模型中，概念是用來建模的，這種做法充分利用了面向對象設計的優勢，你可以使用到面向對象的所有特性，包括封裝和繼承，而同時又無需受到數據庫結構的限制，這就意味着實體並不會察覺到絲毫有關底層使用的持久化機制。領域模型是由需求驅動的，且僅需要你理解問題領域，並用類對於邏輯建模。實現領域模型主要的障礙是對象和關係型數據庫之間的不匹配，領域模型是一個面向對象的設計，和數據庫或其他應用程序的約束完全無關，而今受限於其建模的業務流程，這意味着同樣的領域模型可以重用於其他需要同樣邏輯的任意場景。模型是和業務相關的，且僅和業務相關。
參考《Microsoft .NET 企業級應用架構設計》第四章業務層
