明月松間照 清泉石上流

先從后端的dao說(shuō)起吧：
已有項(xiàng)目的開(kāi)發(fā)以及appfuse的開(kāi)發(fā)，都屬于傳統(tǒng)的開(kāi)放方式，內(nèi)部有dao，外部還有service。

這樣的開(kāi)發(fā)方式太學(xué)院了，每次改動(dòng)其實(shí)影響面很大，要改二個(gè)類，兩個(gè)接口。平時(shí)不忙的時(shí)候也就算了，項(xiàng)目一緊的話，大家就亂來(lái)的了。相當(dāng)部分都是最外層接口實(shí)現(xiàn)類就直接訪問(wèn)了數(shù)據(jù)庫(kù)，而不走規(guī)范路線。

現(xiàn)在對(duì)外提供一個(gè)repository的service接口（加載該領(lǐng)域模塊的root對(duì)象，以便程序利用root對(duì)象來(lái)游走，ddd推薦的做法），然后內(nèi)部有一個(gè)dao接口，繼承該repository接口，提供一些內(nèi)部使用的額外服務(wù)，比如一些數(shù)據(jù)庫(kù)查詢。接著有一個(gè)類繼承框架提供的如spring的HiberanteTemplate同時(shí)實(shí)現(xiàn)dao接口，這樣來(lái)改動(dòng)的規(guī)模就比較小，一個(gè)接口和一個(gè)實(shí)現(xiàn)類。這個(gè)思路和SS2的思路是一樣的。

框架數(shù)據(jù)訪問(wèn)已經(jīng)提供一些公共的操作簡(jiǎn)化開(kāi)發(fā)，當(dāng)然還利用泛型等。此外，Ibatis3.0的設(shè)計(jì)思路，將是下一步的工作目標(biāo)。

另外：通過(guò)root對(duì)象游走訪問(wèn)領(lǐng)域?qū)ο螅阅芸赡苡悬c(diǎn)問(wèn)題。但這是可以接受的，因?yàn)閺拈_(kāi)發(fā)的角度看，通常都root下的對(duì)象都是和root對(duì)象一起出現(xiàn)操作的，不可能單一出現(xiàn)一個(gè)root以外的對(duì)象來(lái)操作以及顯示的。

現(xiàn)在就說(shuō)說(shuō)Web層：
由于servcie對(duì)外都是開(kāi)放domian model了，不再提供VO對(duì)象，免去無(wú)謂的copy property操作。而把VO的這部分工作交給自行開(kāi)發(fā)的界面設(shè)計(jì)工具，因此在設(shè)計(jì)頁(yè)面的時(shí)候其實(shí)已經(jīng)知道的頁(yè)面的訪問(wèn)的元素以及對(duì)象路徑，在設(shè)計(jì)頁(yè)面完成后由該設(shè)計(jì)工具生成VO對(duì)象和映射對(duì)象。這樣VO對(duì)象的設(shè)計(jì)產(chǎn)生，以及property的copy都是工具完成，無(wú)須人工干預(yù)。

另外Web層采用SWF，除了完整的抽取出流程控制流轉(zhuǎn)邏輯，還完整的封裝了對(duì)于Request以及Response的數(shù)據(jù)訪問(wèn)操作。這樣一個(gè)流程中調(diào)用了那些model以及servcie都非常清楚。將來(lái)有可能通過(guò)工具像規(guī)則引擎那樣可以提供給業(yè)務(wù)人員直接使用。同時(shí)沒(méi)有了傳統(tǒng)的Control類結(jié)構(gòu)的存在，極大的提高了開(kāi)發(fā)效率問(wèn)題。

模塊邊界的處理包括兩個(gè)部分：
一是行為的邊界集成上，比如訂單管理模塊對(duì)財(cái)務(wù)模塊的行為要求。
訂單管理模塊自行設(shè)計(jì)它所需要的接口，由一個(gè)集成模塊提供adapter類，來(lái)適配到財(cái)務(wù)模塊合適的service上。這樣就解決了舊系統(tǒng)設(shè)計(jì)現(xiàn)有的問(wèn)題，舊系統(tǒng)現(xiàn)在都是直接調(diào)用財(cái)務(wù)模塊提供的API，這樣的做法實(shí)際上是把集成工作放在了訂單管理模塊下。

二是對(duì)象的邊界集成，是這樣做的。
訂單明細(xì)對(duì)象（OrderItem）會(huì)關(guān)聯(lián)一個(gè)產(chǎn)品對(duì)象，不過(guò)產(chǎn)品對(duì)象是是屬于產(chǎn)品模塊而非訂單模塊，對(duì)于訂單模塊只關(guān)心id而并不使用對(duì)象，但在規(guī)則引擎或者界面設(shè)計(jì)工具這樣的集成環(huán)境卻是需要產(chǎn)品對(duì)象的。我們采用代碼生成的方式，在訂單明細(xì)對(duì)象上加一個(gè)annotation，比如Integration的annotation標(biāo)識(shí)，使用aspectj在編譯上enhancement生成的class，使得訂單明細(xì)對(duì)象在集成環(huán)境上可以拿到產(chǎn)品對(duì)象，這算是一個(gè)集成方面。

最后是domain model部分：
一類是類似保險(xiǎn)中的保單對(duì)象這樣的長(zhǎng)生命周期對(duì)象；

另一類是transaction交易過(guò)程的對(duì)象，幾乎沒(méi)有生命周期的；

最后一類是request/response對(duì)象。這類對(duì)象以前沒(méi)有識(shí)別，通常和VO混在一起；但是在IAA中以及電信業(yè)的模型是這類對(duì)象是獨(dú)立存在，并被持久化的。
當(dāng)然他們也是幾乎沒(méi)有生命周期的，request對(duì)象建立在增量更新上很有用。

reponse對(duì)象目前沒(méi)有特別用途，依然采用VO處理。

request對(duì)象的建立有兩個(gè)好處。
1. 以前直接更新訂單對(duì)象，雖然記錄了log但是只知道減肥前，減肥后。
2. request對(duì)象的第二個(gè)好處，可以解決一個(gè)業(yè)務(wù)事務(wù)跨越兩個(gè)物理事務(wù)的設(shè)計(jì)問(wèn)題。即一個(gè)業(yè)務(wù)請(qǐng)求可以分多次累進(jìn)完成，比如分兩天來(lái)處理，每天完成一個(gè)部分，但在完成之前，所有操作數(shù)據(jù)都不生效。在沒(méi)有持久化request對(duì)象前，我們只能把操作的數(shù)據(jù)寫(xiě)到臨時(shí)表上。

此外，由于某個(gè)領(lǐng)域模塊的增量操作通常從一個(gè)根對(duì)象開(kāi)始，所依賴的criteria可以從request中加以識(shí)別并通過(guò)框架提前加載，而service對(duì)象的方法接受傳遞對(duì)象而不再關(guān)心對(duì)象的加載工作；同時(shí)也可以通過(guò)框架處理基本數(shù)據(jù)復(fù)制工作，這樣程序只關(guān)心關(guān)聯(lián)對(duì)象的操作。這個(gè)做法和SS2是一樣的，只不過(guò)采用的是AOP的處理方式。