(文章後半部份內容跑題了)
有些朋友對乙個具體的業務流程使用何種工作流模式實現總是拿不定主意，
個人覺得設計工作流，其實沒有什麼應該的模式，
用狀態機模式作主流程，管理業務狀態，流模式作子流程，完成具體的業務操作是乙個不錯的方案。
有時業務流程不是一定要用工作流才能實現，有些系統因其型別、規模、應用、成本、時間、開發團隊的技術結構等原因使其不適合用工作流平台實現。
以前做過乙個業務流程，後來我管他叫接力棒模式，流程可以由任何人發起，下一節點的操作人由當前結點的操作人決定，流程只對當前結點操作人與發起人暴露，結點可由發起人與當前結點操作人隨時結束。(業務需求有點類似於：發起人問小張，你對這事有什麼看法，你要沒什麼看法你覺得誰還會有意見,叫他發表一下。一直將該詢問指下去，直到某個被詢問人沒有要推薦的人或發起人覺滿意時，流程就可以終止)
當時設計這個流程時，很頭痛，這個需求與該原系統的授權模，其他的業務流程，以及所用的工作流平台都有點不對路，而且客戶要得還很急，最後沒用工作引擎實現，直接在頁面中推，乙個內容文字框，乙個回覆文字框，乙個選擇下乙個接受詢問者的列表框。有點象電子郵件**的形式。我不想說這個沒有技術含量，不符合設計模式的方案好不好。
不過，在乙個已穩定執行並已結款的系統中，在不改變系統架構的情況下，用5個小時完成了乙個重要客戶的新增需求，我想對公司，對客戶，對團隊都是一件好事吧。
有時最好的技術不一定是專案最適合的，見過有的團隊負責人，為了使用、跟隨、學習一項新的技術，就在專案中及力主張使用新技術，甚至是團隊或他個人都不熟悉的技術。我不想以小人之心猜想該負責人的真實想法，不過經常是該專案砸了，該負責人在專案開發中學會了該技術，找到了一家更有發展的新公司大展巨集圖去了，讓公司(原來的)，讓並肩作戰的兄弟們(原來的)，陷入了乙個泥潭。
我主張在專案中使用新的技術(私心成份也不少)，但是個人覺得將新技術應用到實際專案之前，還是應該進行一次評姑比效穩妥.......
今天酒喝得少了些，
又跑題了，
又開始胡說八道了，
又要被人罵了........................
工作流模式
工作流模式 工作流原理上有很多特定模式，可以用於工作流過程建模和分析。在研究工作流引擎時，這些是必不可少知識儲備 基本模式 5個 1 順序模式 按照順序執行各項活動，工作流流程中的乙個活動只有當另乙個活動完成後才能進行。如 當訂單登記活動完成後，客戶通知才可以進行。2 並行分支模式 同時執行兩個活動...
工作流模式
工作流原理上有很多特定模式，可以用於工作流過程建模和分析。在研究工作流引擎時，這些是必不可少知識儲備 基本模式 5個 1 順序模式 按照順序執行各項活動，工作流流程中的乙個活動只有當另乙個活動完成後才能進行。如 當訂單登記活動完成後，客戶通知才可以進行。2 並行分支模式 同時執行兩個活動。在流程中的...
工作流模式
21種工作流模式 基本模式 5個 順序模式 按照順序執行各項活動 並行分支模式 同時執行兩個活動 同步模式 同步兩個並行的執行執行緒 單選模式 從多條路徑中選擇乙個執行 簡單合併模式 合併兩個二選一路徑 高階分支與同步模式 5個 多選模式 從多條執行路徑中選出幾條 同步合併模式 合併多條路徑，如果有...