.NET企業級架構解決方案:業務層
引言
Martin Fowler說過：“任何人都可以寫出計算機才能理解的代碼，只有寫出人能理解的代碼的程序員才是好程序員。”
每一個復雜的軟件都應該按層來組織。每一層代表系統的一個邏輯部件。尤其是，業務層的模塊包括了所有使得系統運行的時候和其它層交互所需要的功能算法和計算，其他層包括數據訪問層DAL和表現層。
業務層是任何分層系統的神經中心，包含了大部分的核心邏輯。因為這個原因，它也經常被叫做：業務邏輯層BLL。
正文
1、業務邏輯層是什么
抽象的講，業務邏輯層是系統的一部分，用來處理和業務相關的任務。本質上，業務邏輯層包括一系列執行數據的操作。數據被模型化為問題域的實體，例如：發票、用戶、訂單、清單。另一方面，包括一些操作，例如：創建一個發票，添加一個用戶，處理一個訂單。
2、剖析業務層
如果你從縱向來看業務邏輯層，你會發現一些業務模型的實體，表達用戶策略和需求的業務規則，實現自動化功能的服務，定義文檔和數據從一層流轉到一層的工作流。
安全是一個在所有層都需要考慮的嚴重問題，但是在業務邏輯層，代碼扮演一個用戶界面層的守門人。在業務邏輯層的安全是以角色為基礎的，或者是限制對業務對象的訪問，只對授權用戶開放。
2.1、領域對象模型
領域對象模型更傾向于對整個系統提供一個結構化的視圖，包括實體的功能描述，實體間的關系，實體的職責。模型產生于用戶需求，使用UML的用例圖和類圖進行文檔化。在模型中，你表示出用來存儲數據和暴露操作的真實世界元素。每一個實體代表模型中的一個角色，提供一些行為。每個實體都有自己的職責，依據領域的關系進行交互。
很多應用被打上復雜的標記，實際上，如果你看到最終的技術實現，你會發現是相對簡單的。但是，整體來看這個應用是復雜的，那是因為領域內在的復雜性。通常來說，困難在于構建一個適當的軟件模型，而不是最終的實現。一個設計良好的模型，無論你運行到哪里，可以解決任何難度的復雜性。
對象模型和領域模型
為了清晰起見，讓我們確定一下“對象模型”和“領域模型”這兩個詞。盡管我們經常會交替使用，實際上他們代表不同的事物，就算代表同一個事物的時候，他們的抽象級別也是不同的。我們所謂的“對象模型”就是簡單的對象圖。對于如何設計和實現模型沒有限制。如果你有了一些相互關聯的類，就有了一個對象模型。就像你看到的，描述相當通用，適用于大部分的解決方案。
我們所謂的“領域模型”就是另外一回事了。領域模型是用來滿足一系列需求的對象模型。典型的，領域模型中的類沒有持久層的概念，是一種與其他幫助類庫中的類沒有關系的理想狀態。另外，領域模型設計用來解決特定的領域問題，試圖從實體和它們之間的關系來抽象業務流程和數據流。
記住領域模型也是一種特殊的設計模式，在后面我們會討論。
2.2 領域實體
從外部來看，業務邏輯層就是對業務對象的一系列操作。大多數情況，一個業務對象就是一個領域實體的實現，也就是一個封裝了數據和行為的類。也可能是一些實現特殊計算的輔助類。業務邏輯層決定業務對象之間如何交互。它也為參與交互的模塊、業務對象強加了一些規則和流程。
業務邏輯層處在一個分層系統的中間，和表現層、數據訪問層交換信息。業務邏輯層的輸入和輸出不是非要業務對象不可。在大多數情況，架構師更傾向于在跨層之間使用DTO(Data Transfer Objects)進行數據傳輸。
業務對象和數據傳輸對象有什么不同呢？
業務對象包含數據和行為，在業務邏輯中可以看做是充血的活動對象。數據傳輸對象只是一個值對象，是包含數據沒有附加的行為。處于序列化的目的，在業務對象中存儲的數據需要被序列化到數據傳輸對象中。數據傳輸對象除了setter和getter以外沒有邏輯行為。在模型中，每一個領域實體類可能會對應多個數據傳輸對象。為什么是多個數據傳輸對象呢？
一個數據傳輸對象不是一個無行為的領域對象的簡單副本。相反，一個數據傳輸對象代表一個在特定上下文環境使用的領域對象的子集。例如：在一個方法中，你需要一個只有Name和ID的CustomerDTO；其他地方你可能需要一個有Name、ID、Country、Contract的CustomerDTO。通常來說，一個領域對象是一個包含很多對象的圖，例如：Customer包含orders，orderdetails，等等。
重點
關于DTO和OB的協同使用，可以引出一大串的、無意義的爭論。理論建議在任何情況下都是用DTO來減少層之間的耦合。實踐中，經常會提醒我們已經夠復雜的了，盡量避免不必要的附加東西。作為一條實踐的準則，我們建議在處理少于100個業務對象的模型的時候，你不需要這么做。在這些情況下，DTO和OB很可能很相似。
2.3 業務規則
在現實世界中的組織都是基于一系列的業務規則組成的。你可以爭論這些規則的級別，但是不可以否認這些規則的存在。每一個組織都有追求的戰略，規則是實現戰略的主要規范。戰略指明了要達到的高度，規則明確了如何達到這個高度。
規范業務規則有各種方式。如果你生活和工作在一個***的世界，每一個組織維護他自己的規則數據庫，這樣在一個項目中的各個團隊中就很容易共享這些規則。大多數情況不是這樣的，搜集業務規格的過程開始于開發項目。結果就是，業務規則在項目快要結束的時候才整理出來，而且是在架構師之間共享。
原文標題：用微軟.NET架構企業解決方案 學習筆記（四）業務層
鏈接：http://www.cnblogs.com/virusswb/archive/2010/08/20/architecture-microsoft-net-solution-4.html
【編輯推薦】
