使用 Spring AOP 與 AspectJ 輕量級編排工作流

引言：為什麼不需要重型 BPM 引擎

當需要實現一個嵌入式、可配置、可擴展的流程流時，引入功能齊全的 BPM 引擎往往過於笨重。本文展示如何利用面向切面編程（AOP）技術，結合 Spring AOP 與 AspectJ，構建一個輕量級、高可配置的流程編排方案，無需獨立流程引擎即可實現活動協調、狀態管理與轉移控制。

問題領域分析

流程的核心要素

• 活動：流程的基本執行單元，操作共享數據上下文
• 共享數據/上下文：活動間傳遞的數據載體，記錄已完成的事實
• 轉移規則：基於已註冊事實決定下一個活動
• 執行決策：評估轉移規則的機制
• 初始化數據：流程啟動時的上下文狀態

架構設計：雙層 AOP 模式

第一層：Spring AOP - 功能層（活動編排）

將流程視為一個空的目標對象（GenericProcess），通過攔截過濾器鏈（每個過濾器對應一個 POJO 活動）來裝配流程行為。這種「攔截過濾器模式」讓流程結構可聲明式配置，活動保持為無狀態的 POJO，實現關注點分離。

第二層：AspectJ - 非功能層（轉移控制）

Spring AOP 基於代理，無法代理已被代理的攔截器。為了解決活動轉移邏輯（基於事實決定是否執行下一個活動）的橫切關注點，引入 AspectJ 的字節碼編織能力，通過 Around Advice 攔截攔截器調用，評估事實註冊表，決定是否執行目標活動。這實現了業務邏輯與流程控制邏輯的完全分離。

案例實現：購買物品流程

流程定義

主流程包含三個活動：校驗物品數量 → 獲得貸記授權 → 配送。每個活動執行後註冊相應事實（如 VALIDATED_ITEM、CREDIT_AUTHORIZED），作為後續活動的前置條件。

關鍵組件代碼結構

• Activity 接口：void process(Object data)，統一活動契約
• GenericProcess：空目標類，僅作為攔截鏈的代理點
• ActivityFilterInterceptor：Spring AOP 攔截器，委派調用 POJO 活動並註冊返回的事實
• TransitionGovernorAspect：AspectJ 切面，環繞通知中評估事實規則，決定 proceed() 或跳過
• Fact Registry：線程安全的事實集合，代表流程執行狀態

配置亮點

• Spring XML 定義攔截器鏈順序與事實規則（如 !VALIDATED_ITEM 表示未註冊時才執行）
• META-INF/aop.xml 配置 AspectJ 載入時編織
• VM 參數 -javaagent:lib/spring-agent.jar 啟用 LTW

優勢總結

• 輕量嵌入式：無獨立引擎，運行於現有 Spring 容器
• 活動即 POJO：不知底層架構，易測試、易作為 OSGi 服務獨立部署
• 關注點分離：業務邏輯、編排邏輯、轉移控制三層解耦
• 狀態驅動：上下文事實自動實現斷點續傳與重複提交保護
• 活動可複用：如「貸記審核」可裝配至任意需該功能的流程