也許是流程做多了的緣故，所以看起程序開發來一切都是流程或者說都包含流程。個人認為大多數的企業應用（不包括特殊應用，例如文檔庫、信息資源庫、BBS等等）不過是對數據以一定的樣式展現（表單），以一定的邏輯對數據進行操作（業務規則），以及把這些處理數據的過程以一定的流程進行管理（流程）。上面三個方面分別對應著表單、業務規則和流程。程序開發中則對應于表單引擎、規則引擎和工作流引擎。而這些方面又可以統一到一個更大范疇的流程上來，所以這里有對流程驅動開發的設想。

先來看看具體的應用場景。

單表增刪改查

這是最簡單的情形，也沒有流程，對這個情形不加討論。但是這里會提到表單引擎，VB里的數據控件非常的易用，沒有PO，沒有DAO，也沒有Service，直接與數據庫字段進行綁定。我們的表單引擎也可以采用這種方式。

支持表單控件（輸入框、文本框、下拉框等）的拖拽，將整個表單與數據庫表綁定。

表單控件與數據庫字段的綁定。

單表業務+流程

比上面的情況稍微復雜一點點，也就是要在業務里引入流程，其實這也是現在工作流引擎應用最多的地方，比如說政府OA里的收文、發文。

這里只需要將表單與流程進行綁定，表單引擎的處理方式不變，依然是直接與數據庫表進行綁定。表單負責對數據庫里的業務數據進行展現，工作流則負責推動這些數據在業務意義上狀態的轉換，互不影響，并在需要的時候在自動節點上對這些數據進行相應的業務處理。

關于表單權限。這個也是表單與工作流進行綁定時所必須考慮到的問題。其實只是需要在表單引擎里引入權限角色的概念，每個角色對應于一種權限，這種權限具體說來就是表單里每個字段的可見、可編輯等等。然后在人工節點定義時指定表單權限角色即可。這樣也實現了流程與表單權限一定程度上的解耦。

其實還有一種更方便的方式，將表單直接與人工節點進行綁定，每個人工節點對應于不同的表單。

復雜一點，多表關聯的情況

復雜一點的情況是業務往往是多表的關聯。這需要對表單引擎做出擴展，讓它可以根據關聯字段對關聯表做出查詢，得到關聯表的設計結構，繼續映射。這讓我想起了ORM，這里很有FRM的意思在里面。其實對于常用的關聯查詢往往有通用的組件可用，例如根據userid渲染出用戶名，根據數據字典的id關聯渲染出相應的值，oa里的正文、附件、印章等等。

流程跨越多個業務

流程需要跨越多個業務，一個典型的流程如下：

會議審批會涉及到兩張業務表：會議室使用表，會議記錄表。在會議申請和領導審批節點，最終用戶打開的都是會議申請的表單，對應于會議記錄表，對該表進行操作。但是流程運行到會議室管理員安排會議室的節點，該節點最終用戶不僅需要看到會議申請的表單同時還要看到會議室使用情況的表單，如果有空閑的會議室，用戶登記操作會議室使用表，然后通知申請者；如果沒有空閑的會議室，則不用登記直接通知申請者。這個過程中跨越了兩個業務，分別是會議室管理和會議管理。表單在各個節點也是不同的。

這其實對工作流引擎提出了比較高的要求。例如如果流程已經結束，會議得到批準，但申請者突然有事要改變會議時間怎么辦？回退。這里的回退無疑就需要有業務的補償，例如要刪除會議室的相關記錄。

應用集成

一個流程不僅會跨越多個業務，也會跨越多個系統。這里的應用場景很多，重要的是要去其他系統抓取數據和操作數據，僅僅靠數據庫表對表單的映射滿足不了需求。

對工作流引擎做出改進，與前面相比，需要由引擎來完成對其他系統服務的調用。這里一個很重要的載體就是XML。首先要定義交換數據所用的XML scheme，然后將這個XML scheme再與表單引擎做出映射。實際執行時，工作流的自動節點會在人工節點前調用其他系統的服務，按照XML scheme將數據轉換為符合定義的XML，在緊接著的人工節點送給表單引擎，表單引擎渲染。修改數據也是同樣的過程，表單引擎將處理后的數據以XML返回，工作流再次做出轉換，調用服務的修改功能。

上面五種都是比較常見的應用場景，理想的情況下，開發方式應該是這樣的：畫出應用流程à定義流程表單à表單與數據庫進行映射à對流程進行業務仿真à完成開發。問題是這樣的：你的表單引擎是否足夠強大？表單與后臺是直接用SQL進行交互的，也就是Transaction Script模式，沒有業務對象，對于復雜業務邏輯如何處理？如何使用規則引擎來解決業務邏輯的問題？權限如何以一種AOP的方式對數據操作進行橫切？

呵呵，純屬個人YY。