隨筆分類(48)

1

public interface CompositeAct extends Act
2

{
3

Act[] getActs();
4

}

一直想系統的整理一下自己有關Domain Model實踐的嘗試。但總覺得自己的想法還不夠系統而作罷。
然而從另一方面看“系統的東西”也許永遠做不到，失去了目標的生活該會多乏味。
因此我決定將自己有關Domain Model設計的有關實踐和思考和盤托出，也算是拋磚引玉。歡迎大家
參與討論，遇到同你的觀點相左的地方，希望能以包容的態度來面對，我們是朝同一方向走的伙伴而不是
相互對視的敵人。：）

在深入討論之前我先拋出一些原則和概念，最后你會看到這些概念和原則的威力。
1.按照概念依賴的原則來組織業務層。
2.將業務活動（業務流程）建模成類。
3.用業務活動（業務流程）作為關聯整個業務層各種對象的骨架。
4.在業務活動中鑿出擴展點，使用不同接口分離不同性質業務對象。
5.將對象的存儲理解為業務層概念。
......

概念依賴

這是我認為能否得到良好業務層最重要的概念。
在我系統框架設計將要完成，開始涉及業務層設計時，我腦袋一片空白，書上，大家討論的大多是整個系統的結構從UI層
到服務層到數據訪問層到數據庫。到底業務層該如何組織？Martin Fowler的POEAA的書中沒有回答。找到的相關
書籍也都過于空泛。Martin Fowler的分析模式有些用處，但不夠系統。透過Martin fowler網站，我拿到了
Domain Driven Design的發行前版本。該書給了我很大的啟示。其中的要點有：
關于關聯：
1.Imposing a traversal direction (強制一個關聯的導航方向)
......
關于Responsibility Layers（業務職責層）的劃分：
作者給出了三個指導原則：Conceptual dependency.(概念依賴)為其中一項。
書中給出的描述的是業務職責層上層的對象需要通過下層對象才能在概念上完整，
相反下層對象則可獨立于上層對象存在含義。這樣天然的下層對象相對于上層對象
會更穩定。并且在今后演變的過程中，使同擴展的方式來完善系統，而不是改變對象
的方式。
通過實踐，我覺得這條原則可以應用在任何兩個有關聯的業務對象上。通常可以通過
概念依賴先建立一個導航方向。這能夠滿足大多數的需求。當確實需要反向導航時，
只要理由充分可以隨時加上，并且如果先前將這兩個對象放入不同包中，這時需要
將他們合并到同一個包中。
我見過一個不好的設計。Customer具有很多Flag分別標記該客戶是否掛失，凍結，注銷等等。
通常叫做客戶狀態,然而這是不對的，這違背了單一職責原則。事實上除了注銷外
掛失和凍結都不應該算作Customer的本質屬性。相反我把他們看作某種約束，進而把掛失看作
一種協議.....因為Customer的概念可以不依賴于掛失和凍結的概念，相反掛失和凍結卻要依賴
Customer的概念，應為這是他們動作的主體。
同樣的一開始就讓Customer有GetAccount的方法同樣不好。因為Customer的概念確實不依賴Account
XXXAccount卻可以有Customer的屬性，Account在概念上依賴Customer。
按照概念依賴原則我們能更好的理解業務職責層的劃分。DDD中建議了如下的職責層。
按從高到低分別為：

依賴方向
| Decision
| Policy
| Commitment
| Operation
V Potential

Potential中包括類似Customer,Employee等Party方面的類。對應支持業務。
Operation中包括了核心業務如存取款，買賣以及同這些業務關聯的Account，Product等等。
Commmitment對于客戶包括同客戶簽訂的協議等。對于員工來說包括授權等。
Policy包括計算某種收費的策略，比如電信收費的算法。對應支持業務。
Decision包括主要對應于管理業務。監控系統多在這層。
從上到下觀察，很好的遵循了概念依賴的原則。
從另一方面來看，可以根據概念隨著時間發展的順序來建立對象之間的關系。這樣會天然的滿足概念依賴原則。
后面發展起來的概念可以依賴前面的已經存在的概念，而反過來這不可。這是系統穩定的關鍵。
同客戶簽訂的各種協議可以不斷的發展，但是客戶對象是穩定的。
同理收費的策略可以變化但是最終反映到帳戶上的都只是對Balance的變更。所以收費策略比
帳戶更不穩定。
客戶對象也要比帳戶對象穩定。

從按照穩定的方向依賴的原則出發，我們可以得到對象間的單向依賴。當然也會存在雙向關聯
的對象，然而這種情況在我的實踐中不是很多。而且一旦你懂得了單向關聯的好處后，你就會
謹慎的使用雙向關聯。濫用關聯會使得整個業務層象DDD中說的，變成一大塊“果凍”，你隨便觸動
果凍某一塊，整個果凍都會顫動。
同樣為了簡化設計，對象的關系中多對多的關系盡量避免。如果可以
則通過限定角色轉化為一對多或一對一的關系。
以上是關于概念依賴的觀念，下面讓我們看看如何建模業務中的活動。
有一種做法是使用分析模型中的控制類直接映射到設計中類中。我看來這不是好的做法。
這里談談分析與設計的區別。
從分析的角度來看，業務實體總是被動的。業務是通過控制對象操作業務實體來完成的。
分析時我們是關注是什么問題。這要求我們客觀的來描述現實。
進入設計階段我們關注的是如何解決的問題。控制對象施加與業務實體的操作加入不涉及
第三者，則這個操作可以并入被操作的實體類中。然而分析中控制對象的概念是如此的
深刻，以至于只涉及Customer的ChangePassword方法該放到哪里都成了問題。類不是
“某概念 + 所關心該概念的屬性 + 最終施加與這些屬性上的操作” 的封裝，又是什么呢？
下面的問題是如何建模跨越多個業務實體的操作？
舉個例子：銀行開戶。
現在假設開戶時涉及到下面的一些操作對象。
創建一個Customer對象。
創建一個CapitalAccount對象。
存入一定數額的現金。
記錄一筆開戶流水。
整個業務活動，我可以建模為OpenCustomerAct對象。偽碼如下：

public class OpenCustomerAct extends CustomerAct

{

public void override doRun()

{

Customer customer = Customer.create(

);

CapitalAccount capitalAccount = CapitalAccount.create(customer,

);

capitalAccount.deposit(

);

OpenCustomerLog.create(this);

}

所需的參數通過構造函數得到。
將所有的業務活動都建模成一個Act，這非常重要。甚至你可以在Session中放入一個Act來
表示當前正在進行的業務。所有的擴展都是從Act開始的。
假如你要對Act施加某種檢查，那么對doRun方法進行攔截可以達到該目的。
用例能夠簡化到只剩下流程，同樣道理Act也可以做到這點。
對于象RichClient的交互模式，通常只在最后才提交業務，中間的交互都是在準備提交的數據。
那么在中間調用的方法中可以只new XXXAct而不執行doRun操作。這樣做是因為中間的調用
可能會用到XXXAct來作為上下文。現在我還沒有想好在這樣的中間過程中，如何能夠觸發
植入到donRun前的檢查？或許可以創建一個空doRun的子類覆蓋掉父類實際的操作？
Act

1

public interface Act
2

{
3

Operator getOperator();//誰
4

Date getOccurDate();//在什么時間
5

String getOccurPlace();//什么地點
6

BusinessType getBusinessType();//做什么業務
7

ActState getActState();//業務運行的當前狀態
8

}
9

“誰在什么時間什么地點做了什么業務。”
這描述了任何業務的基本方面。從哲學的角度來看，“我們得到了Act，我們就得到了事物的基礎”。
當我們具體的描述某項業務時，假如需要向調用方暴露特定的屬性。
我們可以隨時添加到Act的子接口中。
例如同Customer相關的Act可定義為：

1

public interface CustomerAct extends Act
2

{
3

Cutomer getCustomer();//針對哪個客戶
4

}

在復雜一點的情況下，如業務需要多人協作完成，可以通過組合模式達到目的。
涉及到一段時間有中間狀態的工作流也應該可以作為Act的子接口進行擴展。
不過我沒有做過這方面的嘗試。

將Act放入Session

將Act放入Session使得可以方便得到業務運行的上下文。而且通過擴展Act。
可以從Act或其子接口中得到想得到的任何東西,這使得任何擴展都成為可能。

這里說明一下Act類的位置應當放入Potential層中，并且與Operator在一起。
因為Potential層的業務對象也需要業務活動來維護。
如果你的框架中Sesion在更基礎的包中，則可以給Act提供一個空內容的父接口,放入Session所在的包中。

1

public interface AbstractAct
2

{
3

}
4

5

public interface Act extends AbstractAct
6

{
7

8

}
9

Session提供得到AbstractAct的入口。
10

public class Session
11

{
12

13

static public AbstractAct getAbstractAct()
14

{
15

return Instance().abstractAct;
16

}
17

18

}

posted on 2005-09-29 00:35 老妖閱讀(535) 評論(1) 編輯收藏

常用鏈接

隨筆分類(48)

隨筆檔案(104)

好友鏈接

我的豆瓣

積分與排名

最新評論

閱讀排行榜


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理