關於暴露業務模型（Exposed Domain Model Pattern）2

GUANPEI發表於2008-07-05
模型AI



核心構件與功能構件的關係
讓我們回到現實世界。軟體系統呈現出連續譜系的特徵，就模型層來說，在其核心存在與功能用例正交的橫切構件，而在其邊緣也存在一些呈現出與功能層有某種程度平行關係的構件，我們稱之為功能構件；它們位於核心層之上，在實現上是核心層的組合；直接位於功能層之下，橫切能力弱於核心元件，支援有限的幾個用例，甚至一個用例。核心元件與功能元件的並存在空間上是任何應用軟體系統的現實結構，在時間上構成一對矛盾，在軟體系統發展演化的歷史上呈現出此消彼長的形態，是系統的動態結構：

實現一個使用者需求，權衡資源，可能以一種直接的、也是狹隘的方式直接針對這個功能，很少或者沒有考慮可擴充套件性，沒有考慮充實、完備一個通用的、抽象的模型，系統增加了一個功能元件。
系統邏輯層的功能元件在積累；這些功能元件集合中的某些邏輯都單獨實現，但實際上具有共享的可能性
開發團隊有了一個合適的機會，將其中具有共享價值的邏輯、計算抽象出來，其結果是：有些功能元件依然存在，但變得較薄；有些喪失了存在的必要性，消亡了。
以上的過程被重複，形成了系統的進化史
如果將第三步去掉，或者沒有抓住時機，系統將急速走向崩潰。主要的設計、重構活動都在第三步，它使系統維持了一種動態的平衡，可持續的發展；在這個過程中，邊緣的功能元件產生、削弱、消亡，沉澱為核心元件。系統的模型核心的強大引力不斷克服使用者需求所產生的離心力，在系統本身的存在發展中起作用。

在這個意義上，我並非否定Façade或者DTO在應用系統體系結構的作用，只不過這個作用要置於以上的過程中來看。橫向來看，核心元件在結構單元中的足夠的比例和份量是系統穩定性和良好擴充性的根本保障；歷史的看，功能元件的向核心層的沉積是系統進化的積極方面。

關於外觀
Façade作為一種被普遍使用的模式的主要價值應該在於用來封裝開發平臺API，它將廣泛適用的、細粒度的、通用的API封裝為粗粒度的適用於某一行業的、領域的直接面嚮應用的API；因此，封裝到什麼程度又是一個折中。平臺提供者和應用系統的構造者各自的視野有巨大差異，在各方面都不對等，這些差異足以導致封裝的必要性。對於應用系統的各個層之間，Façade所起的作用完全不同。關於這個問題就不作更深的探討了。


小結：
與功能用例相平行的結構單元是系統體系結構中的消極因素；它的存在是軟體系統的現實；但在系統良性進化的方向上應該傾向於被消解、吸收、沉澱。正交的、橫切的核心元件是模型的精髓，模型應該發展壯大。






以下的段落來自於POJO IN ACTION，作者顯然基本是Exposed Domain Model pattern的支持者，但他的幾個觀點與我還是有不小的差異。原文沒有翻譯，我的Comment也用英文寫出便於參照。

One drawback of using a POJO façade is that you must write potentially complex and error-prone code to detach domain objects.

(Of course we must do that because we are forced to repeat the model as a set of facades and a lots of DTOs)

A simpler approach, which eliminates the need to detach objects, is to use the Exposed Domain Model pattern. This pattern keeps the persistence framework connection open for the duration of the request, which allows the presentation tier to lazily load objects.

(This pattern does not necessarily keeps the framework connection open, just that the OpenSessionInView do it(Spring); Exposed Domain Model pattern as a methodlogy has no direct relationship with it; In fact we do have other alternatives.)

The presentation tier calls domain services to update the domain objects, as well as repositories to query the database, and then gets the data to display directly from domain entities and value objects. You no longer have to worry about detaching the objects that it needs. However, while this approach reduces the amount of code that you must write, there are some tricky design issues because of how transactions, persistence frameworks, and the servlet API interact. Also, the lack of a façade increases the chance that changes to the business tier could affect the presentation tier. There is also the risk of business logic creeping into the presentation tier. Despite these drawbacks, this approach makes sense for many applications and is becomingly increasingly popular.

(In my opinion the other side is more troublesome: the existence of facades tends to absorb logic that should belong to core model and eventually loads to lots of vertically divided structural elements which is most harmful to the health of the system.)

相關文章