之前立貼改寫Tpflow 到 LaravelFlow 發現很多人還是不懂 什麼事 workflow,今天來講解下。
可以看下帖子原文：分享：LaravelFlow立項研發，立帖為證本月釋出
目前的開發進度，已經完成了設計器，以及簡單審批的對接開發，預計近期將釋出第一個版本。
更新時間：2022年6月4日
什麼是工作流引擎（Workflow Engine ）
開發一個系統，最關鍵的部分不是系統的介面，也不是和資料庫之間的資訊交換，而是如何根據業務邏輯開發出符合實際需要的程式邏輯並確保其穩定性、易維護性（模組化和結構化）和彈性（容易根據實際業務邏輯的變化作出程式上的變動，例如決策權的改變、組織結構的變動和由於業務方向的變化產生的全新業務邏輯等等）。 Workflow 引擎解決的就是這個問題：如果應用程式缺乏強大的邏輯層，勢必變得容易出錯。
就好比一輛汽車，外表做得再漂亮，如果發動機有問題就只是一個擺設。應用系統的彈性就好比引擎轉速方面的效能，加速到 100 公里需要 1 個小時（業務流程發生變動需要進行半年的程式修改）還能叫好車嗎？引擎動不動就熄火（程式因為邏輯的問題陷入死迴圈）的車還敢開嗎？（來源於百度百科）
為什麼要用工作流引擎？
為了解釋這個問題，我們來舉個例子：
應用場景： 張三工程師正在研發一套 OA、ERP 等企業資訊管理平臺
客戶需求： 有個物資系統，客戶希望這麼做，A 填寫申請表 ——B 部門經理稽核 ——C 物資管理部確認 ——D 張三領用物資
張三工程師： 立刻開始了業務需求調研，分析，總結。然後開始寫程式碼了。業務表單很簡單（這裡我們就忽略了）
審批設計：-1 退回修改 0 儲存編輯 1 部門經理稽核 2 物資部門確認 is_use 是否領用
根據設計：寫了如下程式碼：
public function check(){
$code = input('code');
$userId = session('uid');
switch ($code){
case 1: //B核准
//一大堆邏輯程式碼
break;
case 2: //c物資部核准`
//一大堆邏輯程式碼
break;
default: //張三發起申請
//一大堆邏輯程式碼
}
}
}
這時候，張三工程師，很快寫完了程式碼。邏輯也正確，許可權判斷完全沒問題，很高興的跟客戶開始了一系列的騷操作，並稽核通過。
時間過了半個月，軟體還在運維應用期間。客戶給張三工程師打電話，我們領導說，要增加一個稽核功能，
改為：A 填寫申請表 ——B 部門經理稽核 ——E 主任核實 ——C 物資管理部確認 ——D 張三領用物資
問題來了： 而這個客戶系統，有數十條，類似的稽核業務？如果都這樣變動？
這時候，求張三工程師的心裡陰影面積？
總結下： 從上面的例子來說，不能說張三工程師的程式碼邏輯有問題，業務邏輯有問題。但是問題在哪裡？
我個人認為，在於沒有很好處理業務與邏輯之間的關鍵因素。我們常說，資訊管理系統業務是一半，工作流程是一半。如何整合好這兩個關係。需要應用到工作流引擎。
廢話太多，來點實際～
用工作流解決上面張三工程師的問題
李四接手了，張三的業務，全面分析了，下系統。決定開發個專門管理該公司的業務流程問題。 把業務與流程剝離。
通過視覺化快速構建。在 2 分鐘就完成了上面的邏輯架構，同樣的，改造了數十條業務邏輯。而這些，他只用了不到 1 個小時。
張三工程師，不可思議的說，原來還有工作流這東西～～～
總結來了
通過上面的小 Demo 應該很容易看出工作流強大的優勢在於哪裡。
不管你業務怎麼變化，流程怎麼變化，都能通過視覺化的拖拽設計，
把專業的流程驅動交給專業的流程引擎，歸集與統一。
你省去的不僅僅是流程的調研，客戶需求分析時間，
更是你寫 if else 一大堆重複程式碼的時間。
最後回到原題：
深入淺出，工作流引擎。LCDP（低程式碼開發平臺）的出現並非偶然，而是在發展過程中的必然，專業化的表單設計，流程驅動，會打破傳統開發的弊端，為企業在快速構建，資料驅動上提供先進的技術生產力！
最後自己催牛逼下：
歡迎大家關注 LaravelFlow 的開發進度，點贊支援作者，做開源不容易。
本作品採用《CC 協議》，轉載必須註明作者和本文連結