在業務邏輯層中，你會發現一個對業務實體進行建模的對象模型、表達了客戶所有策略和需求的業務規則、實現了自治功能的服務，以及定義文檔和數據如何在模塊與層間傳遞的工作流。
1 領域的對象模型
領域的對象模型力求爲系統提供一個結構上的描述，包括每個實體的功能描述、實體之間的關係以及實體的職責等。該模型有用戶需求總結得出，並通過UML用例圖和類圖表示。
業務實體描述了真實世界的元素，其中包括數據和操作。每個實體在模型中都有自己的角色，並提供一定的行爲。每個實體也有自己的職責，並根據一系列領域特定的關係與其他實體發生交互關係。
1.1 對象模型和領域模型的區別
兩者經常互換使用，但實際上他們表述的是不同的概念，至少是同一個概念在不同層面上的抽象。
對象模型僅僅是一系列的對象，並不包含模型在設計和實現上的約束。在擁有一系列相關的類型之後，也就自然地得到了一個對象模型。
領域模型是一個用來實現一系列需求的對象模型。領域模型中的類型並不瞭解持久層或對其他使用到的輔助框中的類型有所依賴。領域模型是針對某個特定的問題領域設計的，力圖對領域中的實體與關係中設計的流程和數據進行抽象。
2 領域實體
從外部來看，業務邏輯層可以看做是一個操作業務對象的機制。一般來說，業務對象（Business Object，BO）不過是某個領域實體（即封裝了數據和行爲的類）的實現。業務邏輯層將確定業務對象之間的交互關係。
業務邏輯層處於分層系統的中間位置，負責表現層和數據訪問層之間的信息交換。業務邏輯層的輸入和輸出並不一定是業務對象。很多時候，更傾向於使用數據傳輸對象（Data Transger Object, DTO）在層之間交換數據。
BO與DTO的區別
3 業務規則
每個真實世界的組織都是基於一系列業務規則運行的。每個組織都有自己要實現的戰略，而業務規則是保證實現這些戰略的主要手段。戰略決定了組織的發展方向，而業務規則給出了實現戰略的具體做法。
業務規則取決於項目的上下文，因此可能會非常不定，充滿變化。這就意味着在業務邏輯層中，規則應該用一種非常靈活的方式實現，最好由專門的規則引擎負責。從最高的抽象層次來看，規則引擎是一種能夠以正式形式接受規則，並將其應用在業務對象上的軟件組件。
4 驗證
業務對象的屬性來自於其映射的實體的屬性，業務對象的方法來自於其自身的職責以及應用到該實體上的部分業務規則。
業務規則在很大程度上是對數據的驗證。換句話說，很多業務規則說到底就是驗證某個業務對象的當前內容。按照這樣的理解，若有專門的驗證層，並讓業務對象通過接口可選擇的支持驗證規則，這樣設計將會非常簡潔。每個業務對象都會暴露出一個接口，讓其他對象可以檢查該對象是否滿足了必要的規則。這樣，設計出一個容易在日後添加新規則的系統也並不困難。
業務對象的狀態驗證僅僅是業務邏輯的一個方面，業務邏輯層還要處理對象之間以及內部信息流程之間的關係。
5 業務流程和工作流
在業務邏輯層，可能需要一些橫切的組件來執行某些專門的計算、強制系統中數據流、安排領域專用的流程來操作業務對象等。
這些組件用來完成特定的任務，例如，自動轉發某類消息、自動計算某些信息、將核心系統和現有子系統進行集成等。
橫切組件還可以作爲工作流存在。工作流與普通類型的不同之處在於，它允許通過邏輯上的圖表來表達任意的邏輯。
下圖所示爲組成業務邏輯層的各個軟件部分。與外部世界溝通的主要途徑是通過一系列全局函數提供的，這些函數會連接到內部的模塊，進而執行計算或工作流。若不使用DTO，那麼業務對象也必須對外公開，讓表現層可以直接實例化。
業務層內部視圖
