BPM、Rule Engine、DDD、SOA
嗯，原本這個網站定義就是筆記本，都只是"借花獻佛"的程式整理筆記，今天倒是花點時間寫寫這個題目。
基本上，這四個東西要怎麼＂兜＂都在一起呢?
DDD 是 Domain-Driven Design，以近年開發理論而言，目前是越來越紅了。
一般目前的專案仍是以 Function 式的開發居多，但理論卻是以OO的派別當紅。
所以我們見到一種現象，有的過多的 OOP，卻沒有幾個 OOD、OOA，那設計出來的東西怎麼可以稱為"物件導向"呢？
好吧，上樑不正下樑歪，即使 OOP再強悍，仍然無法改變路一開始就錯了的事實，所以我們要走OOA。
怎麼走？
畫 Use Case Dirgram，寫scenario，然後畫SSD(system sequence diagram)進階成Seq. diagram，或是使用robustness diagram的方式來倒出 class。
OK，OK，若是沒有使用life cycle或是海平面的Use Case 撰寫方式，你寫出來的還是很有可能是＂功能式＂的開發方式。
假設你有從高層開始寫Use Case，那麼，看來你就可以進行 Domain Model 方式的開發。
怎麼進行 DDD？
ㄟ，這不是這裡要討論的，有興趣的自己去看Domain-Driven Design這本書。
我們假設的是，你已經進行了DDD，擁有了Domain model 這回事。
接著的問題是SOA。
這學問太大，也不全盤討論，我們來看看 Service 這回事就好。
SOA的重點就是"服務"。
服務這件事，該怎麼說呢？
這不是SA/SD/PG 該管的事。
這是人客該規劃的事。
據我認知SOA的一個重點就是，串聯"服務"，各式各樣的"服務"，公司要給外部的"服務"，給內部的"服務"(通常就是各AP如何介接的問題)，基本上就是，利用現有資源，不重新打造輪子。
請問，誰才知道公司的"服務"有啥啊？
除了公司的"supervisor"外，還有誰可能清楚呢？
系統如果過大，需要好幾十個SA 才能訪談完，誰能全盤了解客戶的"服務"是什麼呢？
好，這也不是這裡要討論的事，一樣，假設真的出了個不世奇才，可以定義出公司的服務是什麼，各部門AP的服務是什麼。
接著，就會發現，要善用輪子，可是怎麼串這些輪子？
使用流程，我們可以用最精簡的流程，做出最恰當的事。
我們稱為"經濟路線"。
設計好流程，動線就有了，某個程度上，我們使用 BPM 觀點來看這件事。
所以我們可以輕鬆設計process，可以模擬process 更改之後會發生什麼事，可以將流程重複使用。
可是，會不會設計流程，是差很多的。
了解doamin及流程的人，可能畫 7個步驟就可以處理完，不了解(不熟析)的人，則可能會使用到12 個步驟。
好吧，同樣假設，我們有一個非常熟domain，且了解workflow設計的人。
再來，我們會發現，企業內部有驗證規則、判斷規則。
會在流程進行時，不斷需要驗證、判斷。
這些規則可能很多、很常更新。
這時我們就需要rules engien來幫我們，避免在程式裡一堆if/else，而且還有很多重複咧。
那問題來了。
誰知道有哪些規則可重複使用？
誰知道規則衝突時的優先順序？
(例如：在不同時間，人們分別建了這兩條規則：
1.如果XYZ公司的股價低於10歐元，就僅僅買XYZ公司的股票。
2.買所有低於100的股票。
哪條優先?
)
所以我們需要什麼？
非常熟悉Domain的人來協助分析。
然後呢？
我們用了DDD抽出Domain model，然後知道了公司/企業的內外"服務"有哪些，將Domain model 與 定義的 process 結合，加入 Rules 的設計。
或者，業主已經有了 process 的設計，我們就以process 為主軸，設計出Domain Model（這時可能是考慮＂程式+DB＂與process的整合問題），配合Rules engine的使用。
whatever，重點是：
我們哪來的張無忌，可以整合這些觀念設計啊？
好吧，假設我們有一個小組，裡面有4個身懷絕藝的好手，專門處理這些事。
不要忘記，在目前的IT戰國時代，你還要將所選的產品整合起來，加上部門的AP設計，組成一個大系統。
如果你用的又是Java的話，你可能還有Architect team在幫你設計。
JSF/Spring MVC/Struts/wicket.... + spring + Hibernate/iBatis/....
加上整合到 BPM / Rules Engine的 API。
喔喔！！
看來一個張無忌也不夠了.......
關於此篇文章的種種，有機會再分專題來討論吧.......(我想，應該是不會有機會的了 .... :D )
0 意見:
張貼留言