我們規定UI層只能使用無行為的DTO對象，通過分析，我們發現大部分的界面都可以使用和Domain對象內容一致的DTO對象，比如Domain里面有Order->OrderItem這么個Domain對象的聚合體，在UI的某個界面往往也正好只需要同樣的數據聚合體。所以我們劃分出EntityDTO和FlatDTO的概念，EntityDTO和Domain對象一一對應，只包含Domain對象的數據，DTOAssembler有工具可以自動完成這兩者的映射，FlatDTO就是任意數據內容的組合（和PEAA里面的DTO的介紹一致）。

物理結構：
系統UI和Business層物理分離的，通過Remoting通信，公司之前的這種Remoting結構的系統一直存在兩個問題，1）因為WinForm提供了豐富的界面操作，有的人為了使用后臺和業務相關的邏輯頻繁的調用Remoting對象，完全不考慮效率，大部分操作背后都進行了若干次的Remoting調用,2）有的人考慮到了效率，把很多不訪問到后臺資源的檢查和邏輯都寫到UI層，這樣導致邏輯分散難于管理難于重用。（我承認UI必不可少得包含一些邏輯，比如非空輸入檢查，這種檢查往往UI和Domain都需要做的，但有些業務特別是計算還是只由Domain去處理好些）

為了緩解上述兩個問題，我考慮了另外一種稍微有點怪異的結構。因為UI層對RemoteFa?ade依賴于實現，而非倚賴于接口，所以我們的后臺組件必須全部部署到客戶端（ok，我知道這樣不好，或許我會寫篇文章來介紹這其中的權衡），也就是說，如果不使用到后臺資源，我們完全可以在客戶端直接使用Domain，所以我們設計了LocalFacade和RemoteFacade兩個組件.RemotingFacade都是Remoting對象，UI層如果訪問RemoteFacade對象的話，肯定是要訪問后臺數據庫，后臺文件之類的資源；而LocalFacade是普通對象，如果UI訪問它，則LocalFacade首先將DTO轉化成DomainObject,然后使用Domain邏輯，而這一切都在客戶端處理，速度肯定比Remoting快得多（稍后才看到EJB的Local和Remote接口，不知道它的兩種接口是否可以同時使用）。

這樣處理最明顯的好處就是，從邏輯結構上來講，所有和業務對象本身相關的檢查、計算等所謂的業務邏輯都可以全部駐留在Domain里面，而不會分散到UI層。另外一個好處是，如果客戶端已經拿到了檢查或計算所必要的相關數據，就不用費力的往服務端再跑一趟了。

看到這里，細心的人可能有個疑問，為什么要使用EntityDTO，而不可以把Domain對象直接暴露給UI，這樣就可以省掉EntityDTO的維護，EntityDTO和Domain映射的維護以及映射導致的效率損失（里面有很多反射操作）。Ok，這確實是我也看著不爽或許以后會改過的地方，之前的一些想法包括，１）UI層不應該直接使用Domain的細粒度接口（實際上因為WinForm提供的豐富的界面操作，以及大量的業務檢查，細粒度接口的訪問的概率倒是挺大的），２）Domain對象反轉倚賴于Persistence層的接口，因為我們認為Domain在進行某些檢查或者計算時，它所需要的數據可能還在數據庫里面，所以需要domain自身直接去訪問Persistence層，這種訪問是只讀的，也就是說，寫數據還是必須由Fa?ade層調用Persistence接口去實現。這樣做實際上并非必要的，也可以通過Fa?ade層獲取到所有Domain邏輯所需要的數據，這樣Domain就可以與persistence完全隔離，不過這樣的domain邏輯給人感覺不連貫，相關的討論很多這里就不多說了。因為Domain里面的行為可能回訪問到數據庫，所以，為了避免在UI誤用了這些接口，我們提供了LocalFacade，LocalFacade由后臺對Domain完全清楚的開發人員開發，可以減少這種誤用的可能性，當然這個理由很牽強，畢竟通過測試就可以避免這個問題了。

在使用的過程中，還碰到另外一個頭疼的問題，比如判斷某個定單是否已經發送，可以通過Order.Status =ORDER_STATUS_SENDOUT來判斷，但是UI人員建議提供Order.IsSend()的行為，這個要求如果在后臺的話，無可厚非，畢竟IsSend()的判斷邏輯很可能到后面不僅僅是對一個狀態的判斷，但是如果使用行為的話，就需要調用LocalFacade接口，也就是說OrderLocalFacade需要有IsOrderSent( OrderEntityDTOorder)的接口，然后在接口里面還需要把EntityDTO轉化成DomainObject（要么用N多的反射自動映射，效率降低；要么手動映射，維護成本巨大），然后才能通過Domain的行為來進行IsSend()的檢查，LocalFacade暴露如此細粒度的接口，其維護的成本和發射的效率損失都是讓人很難接受的，要知道，客戶端這樣的需求實際上是非常多的。

總之，權衡是件很頭疼的事，尤其是使用分布式的架構，也難怪MartinFlower,RobJohnson等人都在極力呼吁不要使用分布式的架構。上述的討論主要是針對C/S、Remoting的這種架構，在B/S架構里面根本無須LocalFacade和RemotingFacade的區分，但是也會面臨Web層如何使用Domain邏輯的問題，再加上AJAX的引入，如何解決JavaScript里面直接包含業務邏輯的問題，應該比我這里列出的問題更嚴峻。

最后，我考慮到另外兩種方案，以后或可嘗試，１）后臺使用RichDomain,前臺使用Manager。Manager都是靜態的方法，專門在客戶端處理業務邏輯。優點是效率提高了，不用維護LocalFacade，不用把Domain部署到客戶端，缺點是后臺的業務邏輯會在前臺大量的重復，無法使用到OO的繼承多態所帶來的靈活性。２）前臺不包含邏輯，所有需要訪問到業務邏輯的地方都走一趟服務器，這要求更好的設計利用DTO，盡量減少在一個操作背后往返服務器的次數，優點是開發人員爽了，缺點是客戶不爽了。好象又回到我最早提出的兩個問題上，唯一不同的是，之前的系統在這方面都沒有做特別的分析和約束，不同的開發人員在不同的地方都可能采用不同的方式，整個UI層使用Domain邏輯顯得很混亂，需要把這種無意識的狀態變成有意識的狀態。

-----------
看了age0的回復，感覺誤解有點大，抱歉介紹得不清楚，補充一份概要的部署圖，注意客戶端和服務端的Domain是同一組件，在客戶端運行的代碼，通過人為控制不會去訪問到服務端的資源（雖然domain里面有對存儲層的反轉依賴）