一天，老闆找到我，說要做個簡單的工作流引擎。
我查了一天啥是工作流，然後做出了如下版本：
img老闆：簡陋了點。
老闆又來了：要支援會簽節點。
我又查了一天啥是會簽節點，發現會簽節點就是乙個大節點，裡面有很多審批人，當這個大節點裡的所有人都審批通過後，才能進入下乙個節點。
我想了乙個星期，推翻了原來的鍊錶式設計：
img結構上我做了如下調整:
為了控制審批流程，我設計了一些節點狀態:
借助上述規則，一次帶會簽節點的工作流審批過程如下：
老闆：有點意思。
老闆來了：要支援並行節點。
我查了一下午啥是並行節點，發現並行節點是乙個包含很多審批人的大節點，這個大節點裡任何乙個人審批通過，則該節點就完成。
然後很快就加入了並行節點：
加入新狀態 skip:
舉個栗子?：
img老闆：這個設計新增新節點還挺方便的。
老闆又來了：節點要支援巢狀，比如會簽節點裡有個並行節點，並行節點裡又有個複雜節點，要可以巢狀任意層的那種。
我：其實已經支援了~
img老闆：小夥子有點東西！
老闆又來了：要支援條件節點。
經過幾天的冥思苦想，我加入了條件節點：
img老闆：已閱。
經過一番考慮，我把簡單節點分成了3類：
img老闆：嗯。
老闆又來了：節點可以從前往後審批，那能不能從後往前駁回？
我: ......
首先實現了駁回到發起人的功能，相當於一切從頭開始：
img老闆：你小子偷懶。
駁回到上乙個審批人其實是個很複雜的邏輯，因為工作流中的節點可以無限巢狀，所以如何確定上乙個狀態有哪些審批人並不簡單。
img老闆：閱。
老闆又來了：實現乙個駁回到任意節點的功能。
我發現這個需求並不難實現：
老闆：嗯。
老闆又來了：在普通節點加乙個時間限制，要是在規定時間內沒完成就顯示已超時。
我：還有這種需求?
不過還是實現了。
img此時我明白了需求和頭髮呈負相關，需求越多，頭髮越少。
老闆又來了：加乙個**功能，比如有件事讓你審批，但是你拿不準，那就轉給拿得準的人審批。
馬上我發現這個需求跟以往有本質的不同，以往的工作流的節點關係一開始就是固定的，就是在發起流程之前確定的，
但是現在要在審批過程中更改。
無非是加了一些班，掉了一些頭髮，最終設計了如下方案：
img老闆又來了：能不能再加乙個取消**的功能？
。。。我已經寵辱不驚了，加就加：
img老闆又來了：給每個節點加個前後置條件吧，滿足前置條件才能進入該節點，滿足後置條件該節點才能審批完成。
我的內心：啊老闆再見，啊老闆再見吧再見吧再見吧！
我的嘴：好的老闆，收到收到。
老闆又來了：現在有的工作流已經非常複雜了，審批起來耗時較長，能不能對每個進行中的工作流計算乙個指標：直觀的顯示目前審批進行的百分比。
我：收到。
其實跟之前的需求比起來這個並不複雜，因為不涉及核心邏輯的改動，本質只是輸入一棵樹形結構然後根據不同節點的狀態輸出乙個整數。
經過測試思考，最終敲定的方案如下：
老闆又來了：能不能給每個節點掛兩個可以執行的指令碼，分別在開始審批該節點和審批完成該節點後執行？
我：收..到。
後來我當然實現了這個功能，同時也發現正值壯年的我已經禿了。
工作流引擎設計思路
http www.cyanine.cn 編輯 收藏引用 網摘 所屬分類 工作流技術 net開發心得 專案管理 系統設計 自開博以來不斷有朋友來 工作流引擎該如何設計 工作流的資料庫如何設計 應用筐架如何搭建等，這些問題其實都是很難有答案的。開發設計乙個工作流引擎是要能夠幫助客戶營造價值，而不是為了一...
工作流引擎設計思路
開發設計乙個工作流引擎是要能夠幫助客戶營造價值，而不是為了一時興趣實現某些技術特性。工作流管理聯盟 workflow management coalition,wfmc 早已定義了工作流技術的標準體系，但並未指明具體實現的方法。工作流引擎在實現方法上可以基於不同的軟體技術架構，引擎本身應該是與具體業...
工作流引擎設計思路
自開博以來不斷有朋友來 工作流引擎該如何設計 工作流的資料庫如何設計 應用筐架如何搭建等，這些問題其實都是很難有答案的。開發設計乙個工作流引擎是要能夠幫助客戶營造價值，而不是為了一時興趣實現某些技術特性。工作流管理聯盟 workflow management coalition,wfmc 早已定義了...