業(yè)務(wù)邏輯層是專門處理軟件業(yè)務(wù)需求的一層，處于數(shù)據(jù)庫之上，服務(wù)層之下，完成一些列對(duì)Domain Object的CRUD，作為一組微服務(wù)提供給服務(wù)層來組織在暴露給表現(xiàn)層，如庫存檢查，用法合法性檢查，訂單創(chuàng)建。

業(yè)務(wù)邏輯層包含領(lǐng)域?qū)ο竽Ｐ停I(lǐng)域?qū)嶓w，業(yè)務(wù)規(guī)則，驗(yàn)證規(guī)則，業(yè)務(wù)流程。1：領(lǐng)域?qū)ο竽Ｐ蜑橄到y(tǒng)結(jié)構(gòu)描述，包含實(shí)體功能描述，實(shí)體之間的關(guān)系。領(lǐng)域模型處于天生的復(fù)雜性:2：領(lǐng)域?qū)嶓w：業(yè)務(wù)層是一些操作業(yè)務(wù)對(duì)象（BO）的處理。業(yè)務(wù)對(duì)象包含數(shù)據(jù)和行為，是一個(gè)完整的業(yè)務(wù)對(duì)象。其不同于上節(jié)架構(gòu)設(shè)計(jì)中服務(wù)層的簡(jiǎn)單理解提到的數(shù)據(jù)遷移對(duì)象（dto），對(duì)于dto存在數(shù)據(jù)的，不存在行為，dto是bo（ddd中又稱do）的子集，負(fù)責(zé)與特定界面需求的扁平化實(shí)體，dto僅僅是一個(gè)數(shù)據(jù)載體，需要跨越應(yīng)用程序邊界，而業(yè)務(wù)對(duì)象則不會(huì)存在復(fù)制遷移，往往一個(gè)業(yè)務(wù)對(duì)象存在一個(gè)或者多個(gè)數(shù)據(jù)遷移對(duì)象。3:業(yè)務(wù)最大的邏輯就在處理一些列現(xiàn)實(shí)世界的規(guī)則，這也是軟件中最容易變化的部分，這里通常會(huì)出現(xiàn)我們眾多的if-else或者switch-case的地方。也這因?yàn)槿绻f以個(gè)人覺得在我們的項(xiàng)目最應(yīng)該關(guān)系和分離需求的層次。4：驗(yàn)證規(guī)則：業(yè)務(wù)規(guī)則很大程度上也是對(duì)對(duì)象的數(shù)據(jù)驗(yàn)證，驗(yàn)證業(yè)務(wù)對(duì)象的當(dāng)前數(shù)據(jù)狀態(tài)。我覺得在每個(gè)業(yè)務(wù)對(duì)象上都應(yīng)該存在一個(gè)對(duì)外部對(duì)象暴露的驗(yàn)證接口，可以考慮微軟企業(yè)庫的VAB 基于Attribute聲明式驗(yàn)證或者上節(jié)流暢的驗(yàn)證組件：FluentValidation中的FluentValidation驗(yàn)證組件基于IOC的解耦。

業(yè)務(wù)層模式：在常見的業(yè)務(wù)層模式中主要分為過程是模式和面向?qū)ο竽Ｊ健＿^程模式有是事務(wù)性腳本和表模式，而面向?qū)ο竽Ｊ綖榛顒?dòng)記錄模式和領(lǐng)域驅(qū)動(dòng)模式。理論上說事務(wù)性腳本模式是最簡(jiǎn)單的開發(fā)模式，其前期投入下，但隨著項(xiàng)目周期和復(fù)雜度上升明顯，而領(lǐng)域模型（DDD）前期投入較大，但是理論上說是隨著項(xiàng)目周期和復(fù)雜度呈線性增加，當(dāng)然這些都是理論值。

1：事務(wù)腳本模式是業(yè)務(wù)邏輯層最簡(jiǎn)單的模式，面向過程模式。該模式以用于的操作為起點(diǎn)，設(shè)計(jì)業(yè)務(wù)組件，即業(yè)務(wù)邏輯直接映射到用戶界面的操作。這通常是從表現(xiàn)層邏輯出發(fā)，表現(xiàn)層我需要什么業(yè)務(wù)層提供什么，直到數(shù)據(jù)層。針對(duì)沒一個(gè)用戶的新功能都需要新增一個(gè)從UI到關(guān)系數(shù)據(jù)庫的分支流程。其使用與邏輯不是很復(fù)雜或者變化不大穩(wěn)定的應(yīng)用系統(tǒng)開發(fā)。其不需要付出與業(yè)務(wù)無關(guān)的額外代價(jià)，并且在現(xiàn)代VS之類的IDE幫助下能夠很快的進(jìn)行快速應(yīng)用開發(fā)（RAD）。也由于這種優(yōu)勢(shì)，也是其最大的劣勢(shì)，程序中充滿了IF-else，switch-case之類的邏輯或者大量的static的方法，每個(gè)功能都是一個(gè)程序分支，這對(duì)代碼無法重用。編碼不易于維護(hù)，對(duì)復(fù)雜項(xiàng)目和變化需求不適應(yīng)。

2：表模式：為每個(gè)數(shù)據(jù)庫表定義一個(gè)表模塊類，包含操作該數(shù)據(jù)的所有行為方法。作為一個(gè)容器，將數(shù)據(jù)和行為組織在一起。其對(duì)數(shù)據(jù)的粒度針對(duì)于數(shù)據(jù)表，而非數(shù)據(jù)行，因此需要以集合或者表傳遞數(shù)據(jù)信息。表模式基于對(duì)象但是完全又?jǐn)?shù)據(jù)庫驅(qū)動(dòng)開發(fā)，在業(yè)務(wù)模型和數(shù)據(jù)庫關(guān)系模型顯著差異的情況下，應(yīng)對(duì)需求，并不是那么適合。但是在.net中提供的一些列如強(qiáng)類型DataSet等IDE的輔助下自動(dòng)生成大量的代碼，也是一個(gè)不錯(cuò)的選擇，因?yàn)椴糠謹(jǐn)?shù)據(jù)庫的操作趨于自動(dòng)化。表模式?jīng)]太過于關(guān)注業(yè)務(wù)，而是關(guān)注數(shù)據(jù)庫表結(jié)構(gòu)。而業(yè)務(wù)邏輯和領(lǐng)域問題才是軟件核心。

3：活動(dòng)記錄模式：一個(gè)以數(shù)據(jù)庫表一行Row為對(duì)象，并且對(duì)象中包含行為和數(shù)據(jù)的模式方法。其數(shù)據(jù)對(duì)象很大程度的接近數(shù)據(jù)庫表結(jié)構(gòu)。在活動(dòng)記錄模式對(duì)象中通常也包含操作對(duì)象的CRUD行為，數(shù)據(jù)驗(yàn)證等業(yè)務(wù)規(guī)則。對(duì)于業(yè)務(wù)不是很復(fù)雜，對(duì)象關(guān)系與關(guān)系模型映射不具有很大差異情況，活動(dòng)記錄模式會(huì)運(yùn)用的很好?；顒?dòng)模式比較簡(jiǎn)單化設(shè)計(jì)，在上現(xiàn)行的很多如Linq to sql，ActiveRecord框架的輔助下，將針對(duì)問題領(lǐng)域不是太過復(fù)雜的項(xiàng)目十分有用。但是其模式和數(shù)據(jù)庫表結(jié)構(gòu)的相互依賴，導(dǎo)致若你修改數(shù)據(jù)庫結(jié)構(gòu)，你不得不同時(shí)修改對(duì)象以及相關(guān)邏輯。如果不能保證數(shù)據(jù)庫關(guān)系模型和對(duì)象模式的很大程度的相似這就進(jìn)入的困境。

4：領(lǐng)域模型：在前面的幾種模式都是項(xiàng)目開始站在了以數(shù)據(jù)為中心的角度，而不是業(yè)務(wù)本身的問題領(lǐng)域。而領(lǐng)域模型關(guān)注系統(tǒng)問題領(lǐng)域，首先開始為領(lǐng)域?qū)ο笤O(shè)計(jì)。與活動(dòng)記錄模式來說，領(lǐng)域模型完全站在了問題領(lǐng)域業(yè)務(wù)概念模型一邊，與數(shù)據(jù)庫，持久化完成獨(dú)立，其推崇持久化透明（POCO）。其可以充分利用面向?qū)ο笤O(shè)計(jì)，不受持久化機(jī)制的任何約束。其實(shí)完全又業(yè)務(wù)驅(qū)動(dòng)出來的。但是其最大的優(yōu)勢(shì)如上各個(gè)模式一樣也是其最大的劣勢(shì)對(duì)象模型和關(guān)系模型具有天然的阻抗，我們的領(lǐng)域?qū)嶓w早晚需要映射到持久化機(jī)制。還好的是當(dāng)前有NHibearnate,EF,Fluent NHibearnate這類ORM框架輔助。在DDD中包含UOW，倉儲(chǔ)，值類型和聚合根，領(lǐng)域事件，領(lǐng)域跟蹤一類的概念，這將在以后具體說明。

模式的選擇在與架構(gòu)師的決定，這也是架構(gòu)師具有挑戰(zhàn)意義的職責(zé)，需要根據(jù)具體的項(xiàng)目需求，團(tuán)隊(duì)，個(gè)人等外界因素最終決定，不存在萬能的模式，也不存在完美的設(shè)計(jì)。

原文鏈接：http://developer.51cto.com/art/201206/340941.htm