JCCONF 2026 使用現代流程引擎，簡化跨服務多步驟流程開發 & 心得
今年唯第二場社群演講又再度提到了流程引擎，同一個主題講三年，現在對這個主題是越來越熟悉，發現不只流程可以用引擎來編排，簡報又再加了上次沒有的東西，連原來被做成排程的工作應該也要被取代才對，而且 DEMO 的流程很順應該足夠清楚，結尾有點超時蛇尾了，還好該講的重點都點到了，根據詢問問題的聽眾問的細節了解應該是有聽懂，這次結果還不錯啦！只是未來不好意思同主題在同一個研討會上再講個第四年，另外找方式持續推廣就好。這次提問的聽眾，聽的蠻仔細的，問的細節也很有趣。
技術
這次特別先建立了一個相對完整的專案，不只是為了流程引擎，也是把 DDD 跟 EDA 做一個完整學習。
專案裡面以多步驟的倉儲履約流程為例子，雖仍是簡化版，但應該足夠複雜了，「模擬下單 > 配貨 > 倉內作業 > 模擬揀包 > 出庫 > 完成訂單」
zhjiangexe
一個專案做兩種架構，主要有仔細整理的就前段配貨邏輯 inventory-context，後段倉內作業就僅是範例方法，能夠讓訊息驅動串起來就好。
整體架構用領域驅動設計做起來，決定 domain / context / module / package / class / method 等分類及名詞真的是很痛苦 XD 然後才分別弄訊息驅動架構跟引用 Temporal 進來的編排架構。
一開始先做訊息驅動架構串起全流程，Outbox Pattern + Kafka CDC + Retry 全部都用上確保訊息能傳遞成功，包含 Inbox Pattern 確保冪等性，這些東西得要有共用模組，一個團隊各做一套 Debug 就飽了。
最後才把主流程重新用 Temporal Workflow 包起來(模擬配貨 > 倉內作業 > 完成出庫 > 完成訂單)，要把 Workflow 寫得乾淨也花了很大功夫，因為動到已經寫好的訊息驅動架構原本的部分，最好一開始就要熟悉兩種流程編排模式及解耦方式。
關於領域驅動設計，雖然一直以來寫 Java，它是物件導向語言沒錯，但如果撰寫方式還是用程序式 (Procedural Programming) 的寫法，或者物件的資料跟行為是分離的，對於業務全貌的理解其實會很破碎。
而領域知識只會是更複雜的複合呈現，如資料結構 + 設計模式 + 演算法，用一般程序性寫法或者只懂設計模式皮毛的時候，還是會回到整個程式流程充滿雷雷的 getter / setter，所以這研究過程意外地有學到兩個新模式：
- Demand and Supply 模式：是物流倉儲領域多階段通用的模式，要「考量資源有限、不能隨叫隨有」；「需求配對及佔用」，從配貨、儲位揀貨、波次、補貨、出貨各階段都會用上。
- Ledger（複式記帳 / 分類帳）模式：「不可變（Immutable）、只追加（Append-Only）、借貸必平衡（Double-entry）」。只要系統中存在「有限資源流轉」、「價值交換」或「極需不可否認性（Auditability）」的場景，都能套用這個模式。橫跨庫存、金融存匯、紅利點數等領域都會用上。
zhjiangexe
Demand & Supply 的段落可以看 planner
額外的點，AI Coding 之下，開發太快了，先前研究到一半的 Quarkus 我也覺得沒必要了，改回用 Spring Boot，有時間倒不如把 Go / Rust / Nest.js 等風格、套件熟悉，開發模板建起來，以後有機會就可以用到，一般應用記憶體資源的使用可以直接砍一半以上。
結尾
想想三年前從一開始連演講都害怕，但想說不管先投稿，結果有上了更慌張，哈哈哈，還請自信教練指導提升心理素質，所有成功跟失敗的後果寫下來仔細盤點思考跟找解決辦法，要把心理準備做好做滿，才說服自己可以做到這件事；到現在相信自己至少內容準備好，就不會愧對來聽的人。目前講了有五場包含工作坊，心理準備是有了，演講功力往高標來看未來還有一大段路要走阿～