業務邏輯層是專門處理軟體業務需求的一層，處于資料庫之上，服務層之下，完成一些列對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，倉儲，值型別和聚合根，領域事件，領域跟蹤一類的概念，這將在以后具體說明，
模式的選擇在與架構師的決定，這也是架構師具有挑戰意義的職責，需要根據具體的專案需求，團隊，個人等外界因素最終決定，不存在萬能的模式，也不存在完美的設計，
鏈接：https://pan.baidu.com/s/1v5gm7n0L7TGyejCmQrMh2g 提取碼：x2p5
免費分享，但是X度限制嚴重，如若鏈接失效點擊鏈接或搜索加群 群號744933466，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/86658.html
標籤：C++
上一篇：詳細介紹軟體架構設計的三個維度
下一篇：架構設計：資料訪問層簡述