明月松間照 清泉石上流

先從后端的dao說起吧：
已有項目的開發以及appfuse的開發，都屬于傳統的開放方式，內部有dao，外部還有service。

這樣的開發方式太學院了，每次改動其實影響面很大，要改二個類，兩個接口。平時不忙的時候也就算了，項目一緊的話，大家就亂來的了。相當部分都是最外層接口實現類就直接訪問了數據庫，而不走規范路線。

現在對外提供一個repository的service接口（加載該領域模塊的root對象，以便程序利用root對象來游走，ddd推薦的做法），然后內部有一個dao接口，繼承該repository接口，提供一些內部使用的額外服務，比如一些數據庫查詢。接著有一個類繼承框架提供的如spring的HiberanteTemplate同時實現dao接口，這樣來改動的規模就比較小，一個接口和一個實現類。這個思路和SS2的思路是一樣的。

框架數據訪問已經提供一些公共的操作簡化開發，當然還利用泛型等。此外，Ibatis3.0的設計思路，將是下一步的工作目標。

另外：通過root對象游走訪問領域對象，性能可能有點問題。但這是可以接受的，因為從開發的角度看，通常都root下的對象都是和root對象一起出現操作的，不可能單一出現一個root以外的對象來操作以及顯示的。

現在就說說Web層：
由于servcie對外都是開放domian model了，不再提供VO對象，免去無謂的copy property操作。而把VO的這部分工作交給自行開發的界面設計工具，因此在設計頁面的時候其實已經知道的頁面的訪問的元素以及對象路徑，在設計頁面完成后由該設計工具生成VO對象和映射對象。這樣VO對象的設計產生，以及property的copy都是工具完成，無須人工干預。

另外Web層采用SWF，除了完整的抽取出流程控制流轉邏輯，還完整的封裝了對于Request以及Response的數據訪問操作。這樣一個流程中調用了那些model以及servcie都非常清楚。將來有可能通過工具像規則引擎那樣可以提供給業務人員直接使用。同時沒有了傳統的Control類結構的存在，極大的提高了開發效率問題。

模塊邊界的處理包括兩個部分：
一是行為的邊界集成上，比如訂單管理模塊對財務模塊的行為要求。
訂單管理模塊自行設計它所需要的接口，由一個集成模塊提供adapter類，來適配到財務模塊合適的service上。這樣就解決了舊系統設計現有的問題，舊系統現在都是直接調用財務模塊提供的API，這樣的做法實際上是把集成工作放在了訂單管理模塊下。

二是對象的邊界集成，是這樣做的。
訂單明細對象（OrderItem）會關聯一個產品對象，不過產品對象是是屬于產品模塊而非訂單模塊，對于訂單模塊只關心id而并不使用對象，但在規則引擎或者界面設計工具這樣的集成環境卻是需要產品對象的。我們采用代碼生成的方式，在訂單明細對象上加一個annotation，比如Integration的annotation標識，使用aspectj在編譯上enhancement生成的class，使得訂單明細對象在集成環境上可以拿到產品對象，這算是一個集成方面。

最后是domain model部分：
一類是類似保險中的保單對象這樣的長生命周期對象；

另一類是transaction交易過程的對象，幾乎沒有生命周期的；

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

reponse對象目前沒有特別用途，依然采用VO處理。

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

此外，由于某個領域模塊的增量操作通常從一個根對象開始，所依賴的criteria可以從request中加以識別并通過框架提前加載，而service對象的方法接受傳遞對象而不再關心對象的加載工作；同時也可以通過框架處理基本數據復制工作，這樣程序只關心關聯對象的操作。這個做法和SS2是一樣的，只不過采用的是AOP的處理方式。