業務行為的分析和設計
Author：Anders小明
復雜業務行為通常看作是復雜規則與流程的集合。解決的基本方法依賴基本的思考方式：分解結構。
分解的第一要素是：面向對象——內聚。通常面向對象理論會告訴我們設計的設計原則是：這個對象是什么。這樣的做法對于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，存在的理由不一，有的是出于性能原因，有的出于業務原因（在金融系統中可以看到這樣的例子，例如：為了保證關鍵業務數據的存在，通常是一些價格或者利率，白天提請的交易行為，分為兩步，第一步即使完成，而第二步動作必須在晚上進行）。