最近幾年的工作一直都跟工作流有關，不知不覺之中也積累了一些經驗，收穫了一些教訓。現在拿出來跟大家分享一下。

工作流框架的設計在滿足使用者需求的前提下要儘可能的簡潔、低耦合，流程圖的設計可以採用圖形拖拽控制元件的方式，這樣使用者及維護人員上手最容易。

所以要滿足這一點需要單獨開發一個流程圖設計工具（獨立於框架本身），然後把設計好的流程檔案（一般是xml）通過上傳部署的方式正式啟用起來。 

      獨立設計工具的好處主要是下面幾個方面：

   1、減輕了框架本身的體量，降低了複雜度。框架只需要關注如何支援得到的流程檔案xml 就行了。至於它是怎麼來的，完全不用關心。

    2、獨立設計工具可以作為一個獨立的產品單獨維護和銷售，也更有經濟性。

    3、流程被儲存成一個xml檔案，可以任意匯入匯出，方便備份、部署、帶走和修改。跟應用系統徹底解耦。

    4、流程配置檔案集合在一個xml配置檔案中比拆分成多個xml要更合適。首先，流程的元素複用的可能性很低，沒必要拆分成任務、表單、步驟。。。一大堆出來。其次，一大堆配置檔案無疑大大加重了配置和管理的難度，同時資料庫的相關表結構跟記錄也更為複雜。而把流程相關的一切統統集中在一個配置檔案中則完全沒有這些問題（資料庫甚至都不需要建立相關的配置表）。

     通過版本號來管理流程的版本，每部署一個同名的流程，則自動將新的版本的版本號加1。舊版本仍然保留並處在可用狀態，只是發起新流程的時候預設發起版本最高的那個。如果想走舊的，也是可以的（人工選擇一下即可）。這樣可以有效避免版本丟失導致的歷史資料問題。    

      工作流在實際執行個幾年之後，肯定會產生大量的資料，這些巨量的資料會嚴重影響框架的效能。所以工作流框架的效能問題始終是個不可迴避的難題。

為了解決效能問題，我們必須在設計的時候就應該注意以下幾點。

      1、設計流程框架的時候，把正在跑的流程跟已經跑完的流程區分開（資料庫表級別的區分）。就是說分為兩類表，一類是執行中的表，一類是歷史表，流程一旦跑完，所有資料就被挪到歷史表中，以保證運作中的表資料量始終很少，這樣資料庫的訪問速度就大大提高了。這樣可以有效保證執行中流程的效能。而訪問歷史流程的概率很低，所以對使用者的體驗影響不大

     2、就是統一所有對流程相關的資料查詢，也就是說不是誰都可以寫sql去流程相關的表裡查資料了，而是提供介面，讓其他程式設計師呼叫介面。而介面的實現則由專門的人來負責，這樣就可以根據介面實現的模式針對性的建表索引，也可以加快資料庫訪問速度。

    3、就是把流程的配置簡化，很多流程上面的操作通過設定監聽器的方式分離出去，由其他普通類的方法函式去執行。這樣流程本身的流暢度就不會受這些操作的影響。

   4、把流程相關的資料分成多個表，比如流程定義表、流程例項表、任務表、任務表單表、任務執行物件表等等，儘可能的把資料拆開。這樣可以有效降低資料量，也可以更有效的建立索引。

   5、流程上所有的任務操作在資料庫中的反應都是填加記錄，儘量避免修改記錄（修改資料庫記錄開銷太大）。對任務的重做，也只是再新增一次記錄，而不是把之前的歷史記錄修改掉。

  6、將流程跟報表嚴格剝離開，之前的系統要求在流程任務步驟上展示一些特定格式的報表。這無疑加重了流程框架的複雜度，降低了其效能。其實這些報表完全可以由報表系統獨立承擔，只是其資料來源是從流程表單中獲取而已。工作流只負責工作流，而不負責其他無關的工作。報表功能從工作流上剝離開，也使其自身的報表版本管理變的更容易了。

7、流程圖只是一張image 圖形檔案，只負責向用戶展示目前的流程走向而已，不再負責在其上進行互動和操作。之前的系統對流程圖的要求很高，需要在上面進行復雜的互動和操作，這導致流程圖的繪製非常複雜，效能大受影響，流程的配置也變的極為複雜。這都對將來的維護造成極大的困難。所以將互動的任務從流程圖上剝離開變得非常重要。流程的互動只能通過任務連結的方式。

   在程式碼層面上按照MVC 的模式開發設計。工作流的基礎功能匯聚到幾個靜態類中實現，大部分業務邏輯的實現則通過監聽器來實現即可。程式設計師只需要把精力集中在如何實現監聽器就行了，對工作流框架的侵入性幾乎為零。  徹底的將業務與框架分離開，這樣就基本上可以滿足需求了。