主要介紹業務邏輯層的四種組織方式：
1.Transaction Script(事務腳本)：
面向過程式的組織方式，充斥着大量的業務方法，可能會出現好多重複的細粒度的API，使用比較簡單，易于上手，但是項目過大，會暴露出其問題，不易擴充
2.Active Record(活動記錄)：
該模式比較流行，尤其在底層資料庫模型比對業務模型時，通常，資料庫中的每張表都對應一個業務對象。業務對象表示表中的一行，并且包含資料、行為以及持久化該對象的工具，此外還有添加新執行個體和查找對象集合所需的方法。
在Active Record模式中，每個業務對象均負責自己的持久化和相關的業務邏輯。
是以Active Record模式非常适合資料庫模型和業務模型之間具有一對一映射關系的簡單應用程式，如部落格和論壇引擎，如果已經有資料庫或者希望資料優先的方法來建構應用程式，這也是一個好用的模式，因為這種模式都有相同的增删查改操作，所有可以用代碼生成器生成相應的代碼，好的生成器甚至可以生成驗證邏輯。
典型應用就是結合MVC模式+Active Record ORM
3.Anemic Model(貧血模型)：
有時候會被稱為一種反模式，初看來，該模式和Domain Model模式有些類似，也會找到表示業務領域的領域對象，但是這些領域對象中，不包括任何的行為，這些行為位于領域之外，而讓這些領域對象作為簡單的資料傳輸類。
這種模式的不足之處在于，領域服務扮演更加過程式的角色，和Transaction Script模式有點像，這就違背了“講述不要詢問原則”，就是對象告訴客戶他們能做什麼或者不能做什麼，而不是暴露屬性讓客戶去決定某個對象是否處于執行給定動作所需要的狀态。
4.Domain Model(領域模型)：
可以将Domain Model了解為将要處理的領域的概念模型，事物與事物之間的關系都存在在這個關系中，以電子商務網站為例，購物車、訂單、訂單項等類似的事物都為模型中的事物。這些事物包含資料，當然它們還有相應的行為，以及它所有的業務和領域規則。
Domain Model 越能表示真實的領域越好，這樣就更容易了解和複制業務組織中的業務和規則以及驗證過程。
Domain Model和Active Record之間的差別在于，Domain Model中的實體都不知道如何持久化自己，而且也沒有必要在資料模型和實體模型建立一對一的映射關系。因為Domain Model不知道如何持久化自己，是以需要通過其他方式來做持久化操作，通常來說使用Repository模式，Repository對象負責業務實體的持久化工作。
通常其架構模式如下（依賴自下而上）：
Model層不會引用其他任何項目，進而確定讓他和其他任何設施關注點保持隔離，隻關注業務領域。
Repository層将包含Model層定義的IRepository資源接口的實作，該層引用了Model項目，從資料庫提前并持久化領域對象，Repository對象隻關注領域對象的持久化和檢索。對于有些動作沒有很好的映射到領域實體的方法，可以定義領域服務。試圖在軟體中解決複雜的業務邏輯非常困難，但使用Domain Model模式時，首先為真實的領域建立一個抽象的模型，有了這個模型之後，就可以對複雜的業務邏輯進行模組化：追蹤真實的領域并在領域模型中重建工作流和處理流程。與Transaction Script 以及Active Record模式相比，由于Domain Model模型中不包括通路資料庫的代碼，是以他可以很友善的進行單元測試。但是不足之處在于，如果對于邏輯較為簡單的應用，使用便有大材小用的嫌疑了，而且為了精通該模式，需要面臨陡峭的學習曲線，需要很多經驗和時間上的積累才能很好的使用該模式，模組化時還要全面了解整個領域對象的業務。
AppService是應用程式的門面（網關，API），UI層通過消息與AppService層通信，AppService層還将定義View Model，這些是領域模型的展開視圖，隻用于資料顯示。協調應用程式活動，并将業務任務委托給Domain Model層，該層并不包含任何業務邏輯，該層還将領域實體轉換成資料傳輸實體，進而保護領域的内部操作，并未一起工作的UI層，提供了易于使用的API。
UI層負責使用者輸入，屬于前台使用者展現層，隻與AppService通信，并接受AppService專門為其建立的View Model。