新的需求是客戶希望能夠「提前啟動一些工程階段」——以前是客戶定好了整個流程，全部按照既定的規則執行。
這個也能夠理解，跟我們開發一樣，真正進入開發階段，並不完全是按照詳細設計進行，也未必按照開發計畫走，需求有變化的東西都要擱置，先開發已確定的東西，只管按里程碑交付就行了。
加入這個功能的目的是為了讓「計畫跟得上變化」，還好目前的流程引擎是基於有限狀態機的，功能的擴充套件不會引起整個引擎的邏輯改變。
pm同志說：那是不可能的，豈不是意味著我們的流程引擎失去了作用？
哈哈，對於現在有流程引擎，可能是失去了作用，但是「死流程引擎」上線後可能會馬上失去對客戶的作用才是真的。
流程引擎的乙個重要功能是解釋流程規則，目前大多數workflow、bpm提供的建模工具和我設計的配置工具就是建立這樣乙個流程規則，然後佈署，執行，對每一次執行進行乙個規則持久化，以保證新規則不影響舊資料。如果需要更改，就得重新建流程規則，再佈署。
縱觀軟體工程的發展，從物件導向、面向行為、面向方面、面向事件等程式設計思維，逐漸上公升到面向服務、面向領域、面向流程的業務思維，其根本目的就是實現更靈活的業務改變，統一的口號都是「擁抱變化」。基於事件程式設計的好處是，把具體執行什麼步驟，推遲到執行時刻。
流程引擎也需要做到在執行時刻能夠重定義流程，如果許可權和規則允許的話。這也就滿足了在發生變化的時刻跟蹤並進行改變。再**一點是實現跨流程任務，由使用者決定把哪一些自己的待辦任務合併（workflow pattern中的merge）到一起處理，舉個形象的例子是去洗手間的同時把喝咖啡的杯子拿去洗了^o^而不是跑兩趟~
本來這兩天的任務是解決多工不同處理人的問題，直接需要解決的是把處理人當作流程資料好，還是業務資料好？號稱最靈活的osworkflow也沒有解決這個問題……到現在都還沒個定論，卻噼哩叭啦引出這麼多。
銀行的主要業務流程
1 主體和客體 客戶和會計 櫃員 2 業務發生條件，把業務比作物件 物件由結構和行為構成 結構 憑證和要素，要素涉及客戶的賬號，與之對應的就是會計科目 行為 客戶資金和銀行科目資金，這裡就涉及到了資產負債 共同等科目，以及衍生出的內部賬戶 不涉及利息 和外部賬戶 客戶涉及利息 的概念 有了科目 賬號...
業務流程層的API
netflix api的工程主管daniel jacobson最近在the next web上發表了一篇文章，他表示 我們需要理解誰是api的使用物件，以及他們的使用的方式，並在此基礎上進行api設計。這看起來是顯而易見 理所應當的事情，然而daniel接下來寫道 過去那種傳統的 萬應靈藥 般的面向...
從業務流程角度理解面向服務的概念
從業務流程角度理解面向服務的概念 2005 08 30 15 29 計世網 soa，目前在it領域的熱門主題 面向服務的架構 service oriented architectures。soa的概念來自於web服務，由於web服務概念的出現及相關應用系統的實施，soa架構成為新的web服務模式。從...