工作流引擎四重罪

banq發表於2018-08-16
開源工作流引擎很多，主要以Activiti為主，後來有Camunda等等，但是這些工作流引擎有其基因問題，因為是基因問題，屬於原罪，也稱為四重罪：

1. 對於使用者來說，如果需要精通工作流引擎，必須同時掌握Java語言 BPMN XML語法和圖形符號，需要在這三者之間做到一一對應。 對參與人員的邏輯能力要求非常高，因為這些都是語言符號，只是表達邏輯的形式而已，不如直接用Java開發更簡單方便。

2. 工作流引擎耦合了業務和技術架構，將可靠性（事務）、高效能（Job執行）和業務流程捆綁在一起，比如Job執行的方式就很難擴充到分散式彈性Job方式就比較難。流程事務和技術事務混淆在一起。 隨著serverless和FaaS的興起，K8s + Istio + Knative等將雲架構技術將技術架構變成雲平臺的一部分，在此基礎上使用Knative實現事件驅動的flow流程就更具有擴充套件性和可伸縮性。

3. 工作流引擎違背六角形架構，按照六角形架構，業務核心不應該依賴REST或JMS或資料庫或介面等外圍，一些工作流引擎無法透過Spring那樣對許可權等多切面進行解耦，比如如今流行的OAuth和JWT其實已經剝離了許可權，但是很難結合到現有工作流引擎中，同理，有些工作流引擎依賴於分層架構，比如表單物件其實表單物件應該是一個領域模型物件，但是因為名稱Form原因在實際中要麼會依賴UI層，要麼依賴JPA層，有的人會將其耦合到SpringMVC的Controller或Struts的Action，這導致整個系統的擴充套件性完全喪失，幾乎很難過度到Spring Boot的微服務架構。

4. 將領域模型變成Map裡面的資料，是先有領域邊界？有界上下文？還是先有在這些上下文之間流動的流程呢？流程引擎預設是堅持後者，否定了有界上下文邊界，將領域邊界內的領域模型任意肢解成資料庫的資料，透過Java的Map攜帶，這種不尊重領域模型的極端做法未來必然行不通，只要動態流程，不要靜態結構了，沒有結構，就沒有不變，整個系統好像都可以變，其實是義大利麵條混亂不堪。思路應該是：以聚合根為主，在不同聚合根之間採取非同步的事件通訊，將這種事件通訊和流程管理器整合在一起，如Saga模式。


總結：
工作流引擎其實都是某個階段技術和業務的組裝者，但是由於技術不斷髮展，工作流引擎如果沒有實現模組化或分層化，那麼很難避免隨著技術發展不斷淘汰，使用者也是先嚐甜頭後再嘗苦頭，掉進坑裡，這也是工作流引擎不斷更新迭代，但是鮮有恆強者的原因，但是由於美妙市場的存在，使用者渴求不需要開發人員，以為自己動動滑鼠就能搞定政務系統或辦公系統。

在一個分散式服務環境下，如何整合排程服務走向，Spring cloud代表的微服務路由閘道器給出了一點答案，但是目前閘道器的路由還無法類似BPMN那樣透過XML進行各種流程邏輯組合，未來應該會有，K8s + Istio + Knative代表無伺服器架構就是一個方向。不過，BPMN本身思路方向可能有問題，希望拋棄程式碼和配置，用一套全新的語言表達整個業務流程概念，這種方式必然導致業務和技術的深度耦合。

以上只代表個人觀點。

[該貼被banq於2018-08-16 17:42修改過]

相關文章