分層架構(gòu)與業(yè)務(wù)邏輯實現(xiàn)方式

分層架構(gòu)與業(yè)務(wù)邏輯實現(xiàn)方式一、分層架構(gòu)在當(dāng)今軟件系統(tǒng)中，常用的軟件架構(gòu)思想就是分層，分層思想是現(xiàn)代軟件架構(gòu)的主要思想。無論是企業(yè)級應(yīng)用系統(tǒng)(如：CRM，ERP，OA，電子商務(wù)平臺)，專用軟件(如：OS、SVN、IDE等),還有協(xié)議之類(TCP/IP，OSI等)絕大部分都采用分層架構(gòu)思想進行設(shè)計的。分層(Layer)不一定就是人們常說的二，三層，多層系統(tǒng)，因為這些說法都是分層架構(gòu)的一些具體表現(xiàn)形式，分層是一種設(shè)計思想，也可以稱之為一種軟件架構(gòu)模式(Pattern)，這種思想的核心在于：劃分系統(tǒng)的職責(zé)(Responsibility)如果這個系統(tǒng)的職責(zé)你分析清楚了，你的基于設(shè)計思路差不多就定下來了。你可以去看看，很多的現(xiàn)在代軟件，不是一定是web方面。例如：SVN這樣的源代碼管理軟件、嵯MmInsrfac3□ld>irWriK圖1.Suhversion的架構(gòu)ReroEtavAziceESAW■S/i-4BE立iseivgBer^lc-yDBnaynra叫Urgri嵯MmInsrfac3□ld>irWriK圖1.Suhversion的架構(gòu)ReroEtavAziceESAW■S/i-4BE立iseivgBer^lc-yDBnaynra叫UrgriV，■Hfigicknearsarr&MwngG￡ipi,MjnigfiimarELUfWySJbvflr&lcn知gHterycomnananecllimaup」iCUIAppaClwitLit-rajYApachenod知1n^d汽由I.NETFramework也是分層，Eclipse也是，TCP/IP更加是，還有像操作系統(tǒng)(OS)、編譯器(Compiler),很多流行框架(Framework)也是分層。其實，MVC不也是分層，也就是把模型(Model)、視圖(View)、控制器(Controller)三個不同職責(zé)分開。那我們看看今天的企業(yè)級應(yīng)用系統(tǒng)(很多說是web項目，其他我不認為是這樣，因為web只是一種外在表現(xiàn)形式，我們可以用desktop程序，flash等作為表現(xiàn)形式)，企業(yè)級應(yīng)用系統(tǒng)很多人一說就是三層架構(gòu)，其實確實也是這樣的。即：表示層，業(yè)務(wù)層，數(shù)據(jù)層。當(dāng)然還有其他的分層，如：表示層，服務(wù)層(服務(wù)外觀層)，業(yè)務(wù)邏輯層，數(shù)據(jù)映射層，數(shù)據(jù)層。也有分成：表現(xiàn)層，中間層，數(shù)據(jù)訪問層等等。(注意這些都是邏輯上分層結(jié)構(gòu)一般用Layer，物理上的分層結(jié)構(gòu)，一般講的是部署結(jié)構(gòu)一般用tier)總體上都可以看成是三層：表現(xiàn)層，業(yè)務(wù)邏輯層(也可以說是領(lǐng)域?qū)踊蝾I(lǐng)域邏輯層)，數(shù)據(jù)層。像Spring,Structs、ORM等一些框架，他們都是在不同的層上的相關(guān)實現(xiàn)技術(shù)。二、業(yè)務(wù)邏輯幾種實現(xiàn)方式現(xiàn)在我們再看看，企業(yè)級系統(tǒng)中最核心是哪一層？肯定是業(yè)務(wù)層，因為企業(yè)級系統(tǒng)主要是與業(yè)務(wù)打交道(其實幾乎所有軟件都是實現(xiàn)業(yè)務(wù)，企業(yè)級系統(tǒng)業(yè)務(wù)邏輯主要偏向于商業(yè)邏輯，其他系統(tǒng)，像游戲，自動化控制、支撐系統(tǒng)等把業(yè)務(wù)看成是算法)，而且業(yè)務(wù)是每個系統(tǒng)都不盡相同的。“業(yè)務(wù)邏輯是最沒有邏輯的東西”[FowlerPoEAA,2003]。而且企業(yè)級系統(tǒng)的變化與改變大多都在業(yè)務(wù)層上。那么，做好企業(yè)級系統(tǒng)，首先主要分析好業(yè)務(wù)系統(tǒng)。你可以看看，現(xiàn)今所有的框架在整體結(jié)構(gòu)(spring,structs,等要求系統(tǒng)按MVC結(jié)構(gòu)來開發(fā))，表示層(jquery,extjs等)，與數(shù)據(jù)層(ORM之類)做得最多，有沒有業(yè)務(wù)的框架？(有，但是很少，而且只能是業(yè)務(wù)比較有規(guī)律的地方，像一些財務(wù)系統(tǒng)，有些權(quán)限系統(tǒng)，當(dāng)然還有工作流系統(tǒng))因為業(yè)務(wù)邏輯每個系統(tǒng)都很可能不一樣，沒辦法通用。那么有什么辦法以比較好的方式實現(xiàn)業(yè)務(wù)邏輯呢。現(xiàn)在終于說到主要問題上來了也就是業(yè)務(wù)邏輯(BusinessLogic)的實現(xiàn)方式，也叫做領(lǐng)域邏輯(DomainLogic)的實現(xiàn)方式。一般來說，有以下幾種：事務(wù)腳本(Transactionscripts)領(lǐng)域模型(DomainModel)表模塊(TableModule)活動記錄(ActiveRecord)我們用得最多就是事務(wù)腳本方式（像微軟的Petshop4.0,很多國內(nèi)的三層結(jié)構(gòu)代碼生成工具生成的系統(tǒng)，而且這種方式很多公司，很多企業(yè)級的項目都在用，還有一些框架引導(dǎo)你用這種方式實現(xiàn)）。這種方式最大的特點就是：簡單實用為什么叫事務(wù)腳本（Transactionscripts）呢？也就是實現(xiàn)一個功能，就直接寫一個過程（方法），系統(tǒng)的業(yè)務(wù)就是分散在一個個這樣的過程里，像早期用ASP做的大部分系統(tǒng)，一些使用存儲過程系統(tǒng)等，尤其是使用存儲過程系統(tǒng)，所有業(yè)務(wù)邏輯都寫在存儲過程里，很明顯的事務(wù)腳本實現(xiàn)方式。想一想，我們在業(yè)務(wù)層實現(xiàn)一個業(yè)務(wù)時，一般就是這么做的，要實現(xiàn)一個什么功能，在腦子里想一想，然后找到那個對應(yīng)的類，然后再定義一個方法，加上一堆參數(shù)。就開始寫這個方法的實現(xiàn)代碼，要是邏輯復(fù)雜點，這方法里一堆ifesle，是不是？如果邏輯不復(fù)雜，這種實現(xiàn)到?jīng)]什么問題，也很方便的。而且，有時候，發(fā)現(xiàn)一個類里好多方法，而且大部分是public的。有時候仔細看看，這個類已經(jīng)不再是按面向?qū)ο蠓绞絹韺崿F(xiàn)，雖然你用的是OO語言（java,C#,Ruby等），也用了類，接口，繼承、多態(tài)等技術(shù)手段，但是你是否發(fā)現(xiàn)系統(tǒng)中對象之間的協(xié)作是多么難，甚至你都覺得系統(tǒng)都不存或很少有幾個對象協(xié)作完成一件事情的，有時你會迷惑很多業(yè)務(wù)層的類是否應(yīng)該直接定義成靜態(tài)類就可以了，根本不需要實例化成一個對象。你還發(fā)現(xiàn)，有些方法（功能職責(zé)）根本不屬于這個類或?qū)ο蟮?。這樣一來一去，類的職責(zé)亂了，方法多了，代碼也沒重構(gòu)，越來越亂，最后頭都大了。所以這就是事務(wù)腳本的特點，業(yè)務(wù)不復(fù)雜的系統(tǒng)用這樣方式很方便，對技術(shù)人員要求也不是很高，因為它的實現(xiàn)思維還是按過程方式，大部分程序員都習(xí)慣性這樣，但是一旦業(yè)務(wù)變化復(fù)雜，系統(tǒng)日益不斷的變化，這種方式就變得不堪重負了。領(lǐng)域模型（DomainModel），你也可稱它為業(yè)務(wù)模型，這種方式是現(xiàn)今在國內(nèi)外很多大師級人物提倡的實現(xiàn)方式。這種方式最大的好處，它采用是面向?qū)ο蠓绞絹矸治雠c設(shè)計業(yè)務(wù)邏輯，很多經(jīng)驗不足的人就會反問，難道我用事務(wù)腳本方式就沒有用面向?qū)ο蟮姆绞竭€分析與設(shè)計，我系統(tǒng)里面可全是類、繼承，接口等，那我請問你，你每個類職責(zé)單一（SRP）么？或者說你把每個類的職責(zé)分配好了沒有，就像你會用C#、java、Ruby了，那為何還會有《設(shè)計模式》呢？我想很多人都會沉默一下，其實要把職責(zé)分清楚是一件不容易的事，但也不是不可能，這

需要豐富面向?qū)ο蠓治雠c設(shè)計及程序設(shè)計的經(jīng)驗(很多人覺得不需太多編碼經(jīng)驗，我個人是很反對的，因為只有對程序設(shè)計語言也很熟悉，才直正設(shè)計出優(yōu)秀系統(tǒng)，特別是每種語言在不同平臺、框架還是有細微的差別的)，還要準確理解與把握系統(tǒng)的業(yè)務(wù)需求，再經(jīng)過不斷迭代，精化才最終得出一個比穩(wěn)定的業(yè)務(wù)模型。引申《重構(gòu)》的一句話：“任何傻瓜都能寫出計算機可以理解的代碼，唯有寫出人能容易理解的代碼才是優(yōu)秀的程序員”[Fowler2002]。那是不是：任何了解OO語言的人都會使用類、接口、繼承等特性寫代碼，唯有能寫出職責(zé)分明，結(jié)構(gòu)清晰的代碼才是優(yōu)秀的面向?qū)ο蟪绦騿T呢？“領(lǐng)域模型實現(xiàn)方式，不再是由一個過程來控制用戶某一動作的邏輯，而是由每一個對象都承擔(dān)一部分相關(guān)邏輯”[FowlerPoEAA,2003]。也就是說實現(xiàn)一個業(yè)務(wù)，是相關(guān)領(lǐng)域?qū)ο蟮囊幌盗袇f(xié)作與交互的結(jié)果，不再像事務(wù)腳本那樣直接在一個過程中。這好比一個人要完成一個動作都是人體各個器官相互合作協(xié)調(diào)來完成的，什么時候你見過一個動作，如吃飯，我只要口張開就可以了。因此，領(lǐng)域模型實現(xiàn)方式，它一般會先進行業(yè)務(wù)建模，有時候把業(yè)務(wù)模型也稱之為概念模型，我們在關(guān)系數(shù)據(jù)庫理論里有E-R模型，所以有些人也稱之為實體模型。其實，業(yè)務(wù)，概念模型與實體模型還是有區(qū)別的業(yè)務(wù)模型其實是現(xiàn)實問題域進行分析或抽象，這與實體差不多。但是業(yè)務(wù)模型最終要是用OO方式去試，實體模型要映射成關(guān)系模型。因此，業(yè)務(wù)模型在后期迭代與精化時，不得不采用一些OO手段，如對象職責(zé)(Responsibility)，角色(Role)，協(xié)作(collaboration等。而且實體模型則要考慮關(guān)系映射，查詢優(yōu)化，數(shù)據(jù)冗余的問題。如果你用面向?qū)ο蠓绞絹韺崿F(xiàn)系統(tǒng)，業(yè)務(wù)層實現(xiàn)方式采用領(lǐng)域模型方式來實現(xiàn)是最好的，因為他直接與OO語言映射，思維方式與實現(xiàn)方式統(tǒng)一，所以他可以解決很復(fù)雜的業(yè)務(wù)系統(tǒng)，而且還可以得到很好擴展性，維護性與復(fù)用性。我可以具體說明：例如interactiong項目，那個消息發(fā)送策略，發(fā)送器O1-1+發(fā)送（MessageV消息）：void電子郵件發(fā)送圖二消息發(fā)送模型之前的實現(xiàn)方式是寫了三個方法(SendMail,SendMSM,SendSMS)在一個類里，這一看，顯然的事務(wù)腳本實現(xiàn)方式，根本沒有去抽象與分析當(dāng)前的領(lǐng)域邏輯，沒有用OO方式去分析與設(shè)計當(dāng)前問題，如果那天還要實現(xiàn)一個發(fā)送彩信或者去掉發(fā)送手機短信的功能，那還修改原來的類，這顯示違背對擴展開放對修改關(guān)閉的原則(OCP)。這地方明顯就是一個策略模式。還有，像發(fā)送者，與接收者，消息這些對象都是可以具有行為，因為領(lǐng)域模型是合并了數(shù)據(jù)與行為的對象模型。像Petshop的model層，就是一個貧血模型，一個實體對象沒有任何行為(方法，操作)。現(xiàn)實中確實可以有一個對象沒有行為，但是那肯定是少數(shù)。一般來說，一個對象肯定有數(shù)據(jù)與行為。只有行為沒有數(shù)據(jù)類，就叫無狀態(tài)類(statelessclass)只有數(shù)據(jù)沒有行為，一般用于DTO(數(shù)據(jù)傳輸對象［DataTransferObject］，這在遠程調(diào)用與分布式調(diào)用中常見的一種設(shè)計模式)因此，像這些發(fā)送者，接收者，消息這些類是應(yīng)該具有行為的，像消息解析器，發(fā)送器，這些應(yīng)該是服務(wù)類。所以基于領(lǐng)域模型的系統(tǒng)一般系統(tǒng)分成：表現(xiàn)層(Presentation，應(yīng)用程序?qū)?Application)，領(lǐng)域?qū)?Domain)，基礎(chǔ)結(jié)構(gòu)層(Infrastructure)。應(yīng)用程序?qū)悠鋵嵄容^弱，有時候也可以叫做服務(wù)外觀(ServiceFacade)，有時候可以不需要這一層；領(lǐng)域?qū)樱褪菢I(yè)務(wù)邏輯層，它包括領(lǐng)域?qū)ο笈c領(lǐng)域業(yè)務(wù)的一些實現(xiàn)，還資源庫(Repository)對象，資源庫相當(dāng)于數(shù)據(jù)訪問對象(DAO)，主要用于數(shù)據(jù)訪問，增、刪、改、查(CRUD)等；基礎(chǔ)結(jié)構(gòu)層，可以包括在很多，數(shù)據(jù)持久化(DataPersistence)、ORM、安全機制(Security)、數(shù)據(jù)驗證(DataValidation)、異常處理(ExceptionHandle)、日志跟蹤(Tracing)，緩存機制(Caching)、IoC、AOP等，很多模切(CrossCutting)組件都可以在這層提供。這種劃分，是一種經(jīng)典的領(lǐng)域驅(qū)動設(shè)計劃分，不一定嚴格按此方式。表模塊(TableModule)，我個人認為表模塊應(yīng)該不算是一種業(yè)務(wù)邏輯實現(xiàn)方式，但是根據(jù)MartinFowler《PoEAA》一書，把其歸類到領(lǐng)域邏輯模式中，它是處理某一數(shù)據(jù)庫(其實只能是關(guān)系型數(shù)據(jù)庫)中表與視圖所有行的業(yè)務(wù)邏輯的一個實例。因為表模塊其實就一個數(shù)據(jù)集合(如：ado的RecordSet,

的DataSet中的DataTable或類型化DataSet等之類），它可以看成是一個數(shù)據(jù)容器，因為他用一個類（如Product）表示數(shù)據(jù)庫中對應(yīng)表所有數(shù)據(jù)及行為，我們知道面向?qū)ο竽Ｐ团c關(guān)系模型存在差異，通常一個類與一個實體在概念上相對應(yīng)，也就是一個類對應(yīng)一個表，一個類的實例，即對象對應(yīng)表中某一行記錄。類與表都是抽象的，集合的概念，像關(guān)系數(shù)據(jù)庫中表就一個二維（行、列）的集合，而表模塊用一個類直接表示表中所有數(shù)據(jù)及行為，所以這個類可以不需要實例化，它就相當(dāng)于一個表（如.net的DataTable），這樣所有業(yè)務(wù)操作都直接用表模塊方式進行，從這一概念上來說，它也可以看成是業(yè)務(wù)邏輯的一種實現(xiàn)方式，其實大家肯定可以得出，這種方式在本質(zhì)上還是采用事務(wù)腳本方式來實現(xiàn)業(yè)務(wù)邏輯，只是事務(wù)腳本方式，經(jīng)常要求處理一個業(yè)務(wù)邏輯（如：查找指定ID的Product）就需要用SQL語句從數(shù)據(jù)庫中獲取數(shù)據(jù)，而這種方式先把數(shù)據(jù)庫的所有行加載到表模塊（如：DataTable）中，之后處理所有業(yè)務(wù)都直接與表模塊有關(guān)（如：查找指定ID的行，CRUD之類的操作），這正是表模塊與事務(wù)腳本的細微區(qū)別之后。活動記錄（ActiveRecord），它本質(zhì)上是一種領(lǐng)域模型。它表示一個對象，其包裝數(shù)據(jù)庫表或視圖中某一行且封裝數(shù)據(jù)庫訪問，并在這些數(shù)據(jù)上加上了部分領(lǐng)域邏輯。ParsonlastNarnefirstNamerurnberOfDepandentsins&rtupdatedeleteisFiaggedForAuditEamings圖三一個活動記錄的類從上圖看出，活動記錄對象中封裝了數(shù)據(jù)訪問（Insert、Update、Delete）與相關(guān)的領(lǐng)域邏輯操作，同時活動記錄還有一個特點:活動記錄的數(shù)據(jù)結(jié)構(gòu)與數(shù)據(jù)庫中的結(jié)構(gòu)完全匹配，也就每個類的屬性與表的列一一對應(yīng)，因此活動記錄可能要考慮對象與關(guān)系映射，像一對多，多對多的外鍵映射。如果關(guān)系太復(fù)雜，活動記錄處理起來也比較困難，這些時候需要采用領(lǐng)域模型，因此在MartinFowler的《PoEAA》中把活動記錄不歸類為領(lǐng)域邏輯模式中，而歸類為數(shù)據(jù)源架構(gòu)模式。以上幾種業(yè)務(wù)邏輯實現(xiàn)方式在現(xiàn)在企業(yè)級應(yīng)用系統(tǒng)中都比較常見，其實歸根到底也就是兩種方式：過程化（事務(wù)腳本、表模塊）與面向?qū)ο螅I(lǐng)域模型、活動記錄），這以正好體現(xiàn)兩種分析與設(shè)計問題方法，面向過程方法論與面向?qū)ο蠓椒ㄕ摗Ｖ劣谟媚欠N方式比較好，這沒有絕對的答案，還是那話老話：軟件開發(fā)中不變是變化；沒有最好的，只有最合適的。但是如果你是一個面向?qū)ο蟮闹覍嵎劢z，那么在很多情況，你的第一選擇肯定是領(lǐng)域模型，即便是業(yè)務(wù)邏輯簡單的系統(tǒng)，你也會選擇領(lǐng)域模型。我們通過下表簡單的總結(jié)一下幾個實現(xiàn)方式的特點:實現(xiàn)方式優(yōu)點缺點備注事務(wù)腳本大多數(shù)開發(fā)者能夠理解適合于業(yè)務(wù)邏輯簡單的系統(tǒng)當(dāng)業(yè)務(wù)簡單時，開發(fā)速度很快，代碼可讀性，可維護性也比較好比較適合于在關(guān)系數(shù)據(jù)庫之一構(gòu)建1.當(dāng)業(yè)務(wù)邏輯變化復(fù)雜或變化太大時，會出現(xiàn)大量重復(fù)代碼，而且還很難重構(gòu)，系統(tǒng)可維護，可擴展性很差像Petshop4.0、國內(nèi)很多三層架構(gòu)代碼生成工具生成的系統(tǒng)以及現(xiàn)今國內(nèi)絕大部分企業(yè)級系統(tǒng)（本人估計）都采用這種方式領(lǐng)域模型采面向?qū)ο蠓椒ㄖ苯訉ο到y(tǒng)的問題域進行分析或建模，領(lǐng)域模型直觀地反映現(xiàn)實世界，能夠更好用面向?qū)ο笳Z言模型轉(zhuǎn)換，是一種純OO模型能夠解決很復(fù)雜的業(yè)務(wù)邏輯可以有效地利用面向?qū)ο蟮奶匦裕ǔ橄?，封裝，繼承、多態(tài)等）與相關(guān)技術(shù)（如設(shè)計模式，重構(gòu)等），以提高系統(tǒng)的可擴展性與復(fù)用性。難以學(xué)會如何使用領(lǐng)域型，因為領(lǐng)域模型實現(xiàn)業(yè)務(wù)邏輯時是一系統(tǒng)對象相互協(xié)作完成的，這要求豐富OO分析與設(shè)計經(jīng)驗以及其他專業(yè)技術(shù)能力。要求O/R映射（不過現(xiàn)在已經(jīng)有一些比較好解決方案，如：Hibernate、Ado.NetEntityFramework，還有一些面向?qū)ο髷?shù)現(xiàn)在很多企業(yè)級應(yīng)用項目開始采用此方式，這主要得益于ORM框架不斷成熟，以及模式運動，同時一些設(shè)計原則也比較好解決相應(yīng)問題。請參看參考書目的：11、13、16、6、2、5也可參考DCL與DomainEvent[1][2]模式

據(jù)庫：DB4O，不過關(guān)系型數(shù)據(jù)庫仍然將是主流）3.對開發(fā)人員要求高，要求熟練常握OO及相關(guān)技術(shù)。表模塊適合于系統(tǒng)業(yè)務(wù)較直觀，CRUD操作比較集中如果支持平臺中有比較好工具集支持（如：Ado.Net，數(shù)據(jù)控件之類），開發(fā)速度快，效率高1.當(dāng)業(yè)務(wù)并非CRUD集中型操作，特別是領(lǐng)域模型和數(shù)據(jù)庫表模型差異較大時，難度非常大，因此不適合業(yè)務(wù)復(fù)雜的系統(tǒng)在Microsoft.Net平臺有很多工具集支持，有時候你甚至不需寫一行代碼就可以實現(xiàn)CRUD操作活動記錄使用OO的方式進行設(shè)計與實現(xiàn)，能在一定程度上避免冗余代碼問題）使用活動記錄后，與某個實體相關(guān)的數(shù)據(jù)和業(yè)務(wù)全部集中于活動記錄業(yè)務(wù)對象中，模塊內(nèi)聚性好，便于維護活動記錄適用于不太復(fù)雜的業(yè)務(wù)邏輯，如CRUD等。在此結(jié)構(gòu)下，基于單個活動記錄上的派生和測驗證很有效。需要關(guān)注數(shù)據(jù)之間的關(guān)聯(lián)，在一定程度上帶有數(shù)據(jù)表和影子，沒有完全擺脫數(shù)據(jù)驅(qū)動，所以當(dāng)業(yè)務(wù)領(lǐng)域和數(shù)據(jù)庫結(jié)構(gòu)差距大時，實施困難CRUD是以個體為粒度的，當(dāng)進行批量操作時，如一次查數(shù)千個數(shù)據(jù)，如果嚴格尊從活動記錄就需要生成數(shù)千個活動記錄業(yè)務(wù)對象，這簡直是場災(zāi)難。所以在有大規(guī)模查詢的情況下，可以考慮使用事務(wù)腳本配合活動目錄不適合業(yè)務(wù)非常復(fù)雜的系統(tǒng)你可以使用CastleProject的Active氏皿比框架，或者采用RubyonRails框架表一：幾種業(yè)務(wù)邏輯實現(xiàn)方式的特點參考資料：《企業(yè)應(yīng)用架構(gòu)模式》MartinFowler著；王懷民等譯。-北京：機械工業(yè)出版社2004.7《設(shè)計模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)》（美）ErichGammaRichardHelmRalphJohnsonJohnVlissides著；李英軍馬曉星蔡敏劉建中譯;-北京：機械工業(yè)出版社2000.6《使用Microsoft.NET的企業(yè)解決方案模式》Microsoftpatterns&practices2003.6《HeadFirst設(shè)計模式》EricFreeman、ElisabethFreeman、WithKathyierra、BertBates著；O'ReillyTaiwan公司譯UMLChina改編。-北京：中國電力出版社2007.9《敏捷軟件開發(fā)：原則、模式與實踐》RobertC.Martin著；鄧輝譯。-北京