AsyncLocalStorage 交易傳染：跨模組交易不髒手

跨模組交易是 DDD 分層最容易破功的地方。倉儲系統的一個業務動作要同時動三個模組：容器標記入庫、儲位保留、任務建立——三筆寫入必須同生共死。傳統解法是把 EntityManager 當參數一路傳下去，於是 ORM 概念滲進每一個 domain port 的簽名，四層白分了。

解法：把交易綁在異步鏈上

Node 的 AsyncLocalStorage 可以把一個值綁定到「目前這條 async 呼叫鏈」。我的 TransactionRunner 用它攜帶交易中的 EntityManager：

await this.txRunner.run(async () => {
  await this.containerRepo.save(container);   // 自動拿到 tx-bound manager
  await this.slotRepo.reserve(slot, batchId); // 同一個交易
  await this.taskRepo.save(task);             // 同一個交易
});

Repository 的方法簽名完全不變——它們透過一個 getter 取 repo，在交易鏈內自動回傳 tx-bound 版本，鏈外回傳普通版本。domain port 保持百分之百乾淨。

參與跨模組交易的 repository 採 opt-in：繼承一個 base class 即可，方法本體零改動。刻意不讓所有 repo 預設繼承——沒有跨模組需求的模組不該預付這個複雜度。

巢狀語意：加入，不開 savepoint

服務 A 開交易、內部呼叫的服務 B 又呼叫 run()——B 加入外層交易而不是開 savepoint。內層丟例外，整包回滾。我選「組合流程全有或全無」而不是「內層失敗外層繼續」，因為後者的語意在業務上幾乎總是錯的。

事件派發也要懂交易

交易內派發的領域事件如果立刻執行，listener 會看到未提交的狀態；交易回滾了，Slack 通知卻已經發出去。所以 dispatcher 是 tx-aware 的：交易內派發 → 掛到 commit 後才執行；回滾 → 掛著的全部丟棄。服務的寫法在交易內外完全相同，不需要知道自己身在何處。

至於「commit 後、hook 執行前程序崩潰」的微秒級縫隙——內部事件可以接受，真正不能丟的外部副作用要走 transactional outbox。