在這篇文章中，描述了工作流應用程式從無狀態到有狀態設計的演變。
初始無狀態設計
- 最初建立在 Heroku 的免費 dynos（容器）上，它會在傳入請求時啟動。
- 由於 Heroku 不提供免費儲存，因此使用記憶體 H2 資料庫。
- 由於缺乏持久儲存，工作流必須在一次執行中執行並完成。
- 轉換僅限於從“積壓”到“放棄”、“拒絕”或“接受”狀態。
遷移到有狀態
- Heroku 取消免費計劃後，從 Heroku 遷移到 Scaleway 的免費無伺服器容器。
- 從 H2 移至 Cockroach Cloud 的免費計劃以實現持久儲存。
重構為新的狀態設計，受益於持久儲存時釋放其真正威力。
藉助持久儲存，我們可以在任務完成後暫停流程例項，稍後恢復流程。
為此，我們依賴BPMN 術語中的訊息：
- 任務可以流向訊息事件。
- 任務完成後，流程將等待，直到收到訊息。
- 當訊息發生時，流程將恢復。
- 如果您可以傳送不同型別的訊息，基於事件的閘道器有助於將流程轉發到正確的下一步。
然而，魔鬼潛伏在細節中：任何例項都可以接收訊息，我們可以隨訊息傳送業務key。
好處：
- 透過持久儲存，增加了更多狀態
- 引入“reopen”等新狀態來處理更復雜的工作流程。
- 利用狀態機來建模和驗證不同的轉換。