試圖在軟件中解決復雜業(yè)務問題非常困難，但使用Domain Model模式時，首先為真實的業(yè)務模型創(chuàng)建一個抽象的模型。有了這個模型之后，就可以對復雜邏輯進行建模：追蹤真實的領域并在領域模型中重建工作流和處理流程。與Transaction Script模式和Active Record模式相比，Domain Model模式的另一個優(yōu)勢是，由于它不包含數(shù)據(jù)訪問代碼，因此可以很容易地進行單元測試而不必模擬并隔離數(shù)據(jù)訪問層所依賴的類。另外，Domain Model模式可能并不總能匹配應用程序需求。它的強大之處在于處理復雜的業(yè)務邏輯，但對于只包含非常少量業(yè)務邏輯的應用程序而言，采用一個全方位的領域模型有大材小用之嫌。該模式的另一個不足之處在于，與Active Record和Transaction Script模式相比，為了精通領域模型模式，需要面臨陡峭的學習曲線。需要很多時間和經(jīng)驗才能高效地使用該模式，而且最重要的是，需要對正在試圖建模的業(yè)務領域有全面的了解。
4.1.4 Anemic Domain Model
Anemic Domain Model有時候被稱為一種反模式。初看起來，該模式與Domain Model模式非常類似，仍會找到表示業(yè)務領域的領域對象。但這些領域對象中不包含任何行為。相反，這些行為位于模型之外，而讓領域對象作為簡單的數(shù)據(jù)傳輸類。
這種模式的主要不足之處在于，領域服務扮演更加過程式的代碼，與本章開頭看過的Transaction Script模式比較類似，這會帶來一些與之相關的問題。其中一個問題就是違背了“講述而不要詢問”原則，也就是對象應該告訴客戶它們能夠做什么或不能夠做什么，而不是暴露屬性并讓客戶端來決定某個對象是否處于執(zhí)行給定動作所需的狀態(tài)。
如果考慮用于領域模型練習的示例，那么領域對象Transaction和BankAccount的邏輯現(xiàn)在被剝離出來，它們只是數(shù)據(jù)容器，代碼如下：
鄂公網(wǎng)安備 42010302001612號