業務邏輯層是專門處理軟體業務需求的一層，處於資料庫之上，服務層之下，完成一些列對domain object的crud，作為一組微服務提供給服務層來組織在暴露給表現層，如庫存檢查，用法合法性檢查，訂單建立。
業務邏輯層包含領域物件模型，領域實體，業務規則，驗證規則，業務流程。1：領域物件模型為系統結構描述，包含實體功能描述，實體之間的關係。領域模型處於天生的複雜性:2：領域實體：業務層是一些操作業務物件（bo）的處理。業務物件包含資料和行為，是乙個完整的業務物件。其不同於上節架構設計中服務層的簡單理解提到的資料遷移物件（dto），對於dto存在資料的，不存在行為，dto是bo（ddd中又稱do）的子集，負責與特定介面需求的扁平化實體，dto僅僅是乙個資料載體，需要跨越應用程式邊界，而業務物件則不會存在複製遷移，往往乙個業務物件存在乙個或者多個資料遷移物件。3:業務最大的邏輯就在處理一些列現實世界的規則，這也是軟體中最容易變化的部分，這裡通常會出現我們眾多的if-else或者switch-case的地方。也這因為如果說以個人覺得在我們的專案最應該關係和分離需求的層次。4：驗證規則：業務規則很大程度上也是對物件的資料驗證，驗證業務物件的當前資料狀態。我覺得在每個業務物件上都應該存在乙個對外部物件暴露的驗證介面，可以考慮微軟企業庫的vab 基於attribute宣告式驗證或者上節流暢的驗證元件：fluentvalidation中的fluentvalidation驗證元件基於ioc的解耦。
業務層模式：在常見的業務層模式中主要分為過程是模式和物件導向模式。過程模式有是事務性指令碼和表模式，而物件導向模式為活動記錄模式和領域驅動模式。理論上說事務性指令碼模式是最簡單的開發模式，其前期投入下，但隨著專案週期和複雜度上公升明顯，而領域模型（ddd）前期投入較大，但是理論上說是隨著專案週期和複雜度呈線性增加，當然這些都是理論值。
1：事務指令碼模式是業務邏輯層最簡單的模式，面向過程模式。該模式以用於的操作為起點，設計業務元件，即業務邏輯直接對映到使用者介面的操作。這通常是從表現層邏輯出發，表現層我需要什麼業務層提供什麼，直到資料層。針對沒乙個使用者的新功能都需要新增乙個從ui到關聯式資料庫的分支流程。其使用與邏輯不是很複雜或者變化不大穩定的應用系統開發。其不需要付出與業務無關的額外代價，並且在現代vs之類的ide幫助下能夠很快的進行快速應用開發（rad）。也由於這種優勢，也是其最大的劣勢，程式中充滿了if-else，switch-case之類的邏輯或者大量的static的方法，每個功能都是乙個程式分支，這對**無法重用。編碼不易於維護，對複雜專案和變化需求不適應。
2：表模式：為每個資料庫表定義乙個表模組類，包含操作該資料的所有行為方法。作為乙個容器，將資料和行為組織在一起。其對資料的粒度針對於資料表，而非資料行，因此需要以集合或者表傳遞資料資訊。表模式基於物件但是完全又資料庫驅動開發，在業務模型和資料庫關係模型顯著差異的情況下，應對需求，並不是那麼適合。但是在.net中提供的一些列如強型別dataset等ide的輔助下自動生成大量的**，也是乙個不錯的選擇，因為部分資料庫的操作趨於自動化。表模式沒太過於關注業務，而是關注資料庫表結構。而業務邏輯和領域問題才是軟體核心。
3：活動記錄模式：乙個以資料庫表一行row為物件，並且物件中包含行為和資料的模式方法。其資料物件很大程度的接近資料庫表結構。在活動記錄模式物件中通常也包含操作物件的crud行為，資料驗證等業務規則。對於業務不是很複雜，物件關係與關係模型對映不具有很大差異情況，活動記錄模式會運用的很好。活動模式比較簡單化設計，在上現行的很多如linq to sql，activerecord框架的輔助下，將針對問題領域不是太過複雜的專案十分有用。但是其模式和資料庫表結構的相互依賴，導致若你修改資料庫結構，你不得不同時修改物件以及相關邏輯。如果不能保證資料庫關係模型和物件模式的很大程度的相似這就進入的困境。
4：領域模型：在前面的幾種模式都是專案開始站在了以資料為中心的角度，而不是業務本身的問題領域。而領域模型關注系統問題領域，首先開始為領域物件設計。與活動記錄模式來說，領域模型完全站在了問題領域業務概念模型一邊，與資料庫，持久化完成獨立，其推崇持久化透明（poco）。其可以充分利用物件導向設計，不受持久化機制的任何約束。其實完全又業務驅動出來的。但是其最大的優勢如上各個模式一樣也是其最大的劣勢物件模型和關係模型具有天然的阻抗，我們的領域實體早晚需要對映到持久化機制。還好的是當前有nhibearnate,ef,fluent nhibearnate這類orm框架輔助。在ddd中包含uow，倉儲，值型別和聚合根，領域事件，領域跟蹤一類的概念，這將在以後具體說明。
模式的選擇在與架構師的決定，這也是架構師具有挑戰意義的職責，需要根據具體的專案需求，團隊，個人等外界因素最終決定，不存在萬能的模式，也不存在完美的設計。
架構設計 邏輯層 vs 物理層
layer 和tier都是層，但是他們所表現的含義不同，tier指的是軟體系統中物理上的軟體和硬體，具體指部署在某伺服器上，而layer 邏輯層 指軟體系統中完成特定功能的邏輯模組，邏輯概念。layer是邏輯上 組織 的形式。比如邏輯分層中表現層，服務層，業務層，領域層，他們是軟體功能來劃分的。並不...
軟體架構設計系列總結 8 資料訪問層簡述
在前面簡單描述了下 服務層，soa面向服務架構，架構設計 業務邏輯層，以及一些面面向設計原則理解和軟體架構設計箴言。這篇部落格我們將繼續進入我們的下一層 資料訪問層。無論你用的是什麼開發模式或者是業務模式，到最後最必須具有持久化機制，持久化到持久化介質，並能對資料進行讀取和寫入crud。這就是資料訪...
軟體架構設計系列總結 8 資料訪問層簡述
在前面簡單描述了下 服務層，soa面向服務架構，架構設計 業務邏輯層，以及一些面面向設計原則理解和軟體架構設計箴言。這篇部落格我們將繼續進入我們的下一層 資料訪問層。無論你用的是什麼開發模式或者是業務模式，到最後最必須具有持久化機制，持久化到持久化介質，並能對資料進行讀取和寫入crud。這就是資料訪...