業務行為的分析和設計
Author:Anders小明
同步自:http://www.blogjava.net/AndersLin/archive/2006/12/23/89648.html
複雜業務行為通常看作是複雜規則與流程的集合。解決的基本方法依賴基本的思考方式:分解結構。
分解的第一要素是:物件導向——內聚。通常物件導向理論會告訴我們設計的設計原則是:這個對象是什麼。這樣的做法對於Domain Model或者比較適合,但對應於Service或者Application層的對象並不合適。這一類對象在需求的上的描述最典型是過程式!過程式描述的最大特點是告訴我們怎麼做,當我們應用物件導向設計時,相對於怎麼做,我們要關心的是需求做什麼。
1.1 分解行為的是所有工作的第一步:
分解的過程(手段),可以簡單說有兩個層次:
第一層:把邏輯分解到不同繼承體系的對象上;
第二層:把邏輯分解到同一繼承體系的對象的不同抽象層次上。
兩個層次(手段)的內在的理論是:做什麼其實是一種行為抽象,而正如我們所知的,抽象是有層次和排列的。第一層分解在於解決頂層抽象,而第二層就解決其下層的抽象,如此反覆,就可以完成整個邏輯抽象的排列。
不過,有時我寧願用另外一種更實戰的說法來解釋這樣的做法:利用物件導向方法,關注於做什麼來確定抽象模型,而把怎麼做分解為抽象模型的衍生類別型。
無論是做什麼,還是怎麼做,需要注意的一點是:在知識級上隱式概念的印射,在操作級上有其投影。
接下來我們面臨其它一些技術問題。
1.2 確定邏輯的組合操作關係
在分解行為的過程中,我們先分解出了不同的對象體系,在知識層級(分析層次)上看,工作已經完成,不過在操作層級(設計層次)上看,我們還需要解決一個問題。
不同的對象體系在系統中,根據情境,表現為兩種角色:調用者和被調用者。由於被調用者的派生體系(不同的怎麼做),調用者面臨著一個選擇,選擇一個或者一組合適的被調用對象。
如何選擇有兩種方式:設計時(部署時)和運行時確定。
設計時(部署時)很簡單,在程式中寫上特定衍生類別型,基本算是hardcode。通常發生在調用方其對象體系的葉子節點直接調用被呼叫者的葉子節點。此時,調用者是被動選擇,交給所有的被調用者(通常是葉子節點),每個被調用者採取合適邏輯操作組合。
另一種是運行時,是調用者主動選擇(通過一個工廠),根據一定規則,判斷選取合適的一個或者一組action執行。通常利用外部如資料庫,或者工廠+反射,利用對應被調用者的Specification來確定。
主動選擇可以是簡單的if…else…來完成,當選擇的影響因素多後可以採用的方式是決策表。
兩者比較如下:
|
矩陣/決策表 |
物件導向方式 |
優點: |
直接了當,資訊擷取明確; |
隨相關因素的增長,維護的複雜度曲線平緩升高,低於矩陣,決策表;在與,或,非計算上相對明確;層次化結構有助於學習; |
缺點: |
隨相關因素的增長,維護的複雜度曲線快速升高;但在與,或,非計算上不明確; |
相關資訊擷取不十分明確; |
本質: |
排列組合的平面化結構。這是其優缺點的根源; |
排列組合的層次化結構; |
開發: |
運行時確定,變更相關因素對於開發有重大影響; |
轉化為部署時確定,運行時結構明確 |
在維護成本考慮,應該考慮多態,系統設計上不一定用物件導向編程實現,但在流程和計算設計上至少要類比物件導向的方式;
1.3 行為下的規則
分解後的行為,除了處理怎麼做的流程,還有各種各樣的規則:包括了Selection的Specification外,還包括Validation的Specification,Build的Specification以及Calculation的Specification。
除了後兩種是行為外(不包括它們參數的來源),其它兩種商務規則本身來說,其有三種實現方式:
a) 多態(物件導向方式)。
b) 簡單決策表(映射表),用顯示的行表(and關係)儲存路由選擇(運行時確定)。
c) 樹形決策表(映射表),用顯示的樹表(and/or關係)儲存路由選擇(運行時確定)。
1.4. 行為的非同步分解
大部分行為的分解,都是同步的!然而在複雜系統中還是存在行為的非同步分解,這樣設計看起來更像是Data Flow Pattern,存在的理由不一,有的是出於效能原因,有的出於業務原因(在金融系統中可以看到這樣的例子,例如:為了保證關鍵業務資料的存在,通常是一些價格或者利率,白天提請的交易行為,分為兩步,第一步即使完成,而第二步動作必須在晚上進行)。