如果你對項目管理、系統架構有興趣，請加微信訂閱號“softjg”，加入這個PM、架構師的大家庭
業務邏輯層是專門處理軟件業務需求的一層，處於數據庫之上，服務層之下，完成一些列對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，倉儲，值類型和聚合根，領域事件，領域跟蹤一類的概念，這將在以後具體說明。
模式的選擇在與架構師的決定，這也是架構師具有挑戰意義的職責，需要根據具體的項目需求，團隊，個人等外界因素最終決定，不存在萬能的模式，也不存在完美的設計。
如果你對項目管理、系統架構有興趣，請加微信訂閱號“softjg”，加入這個PM、架構師的大家庭