概念位置

凍結與活解析的分野是狀態所有權問題：凍結參照假設上游資料的 id 在下游生命週期內不會改變，活解析承認 id 可能失效、改由穩定的業務鍵重新定位。這個區分跨越測試與領域設計——領域層決定哪些 id 會被上游操作重建（合併、拆分、歸檔），測試層要覆蓋「重建後舊 id 指向已刪除資料」的劇本。使用語意級假後端自身模擬重建行為，是讓這類劇本可測的前提。

可觀察訊號與例子

操作在特定條件後全部靜默失敗（回寫目標不存在），且單元測試全綠。典型案例：後端合併兩張單據時重建全部明細並更換 id，前端凍結的舊 id 全部指向已刪除資料（T.C5）。修復同樣受盲區支配——第一版只處理單據層 id、遺漏明細層，因為明細 id 在測試裡從未死過。

設計責任

測試設計要回答「哪些上游操作會讓凍結的 id 死亡」，並把每個死亡路徑做成測試劇本。用有狀態的假後端取代 stub（假後端自行模擬重建行為）才能讓活解析邏輯在測試中被真正驅動。「什麼會變、什麼不變」是事實問題——合法出處是可驗的契約文件或一次實測取證，推理與記憶都不算出處。跨邊界的 id 存活規則同時是領域設計的責任範圍。

本章承接 entity 與 value object 的判準 的身份語意討論，延伸到身份跨越系統邊界之後的生存問題；與 狀態轉換與稽核軌跡 的凍結端點段落互補——凍結是時間軸上的問題（何時），本章談的是空間軸上的問題（誰的 id、誰決定它活著）。

參照有效性三問

下游持有上游資料的 id 時，設計階段逐一回答：

1. 對方的哪些操作會讓這個 id 死亡？ 合併、拆分、覆蓋式更新、重建式修復——任何「刪舊建新」的實作都會讓舊 id 失效。盲區集中在業務動詞與實作的語意落差：同一個「合併」，有的實作是搬資料、有的實作是建新刪舊。持有端用前者的假設設計、遇到後者的實作時靜默失效。
2. 有沒有一個跨越這些操作仍不變的身份？ 如果存在——以它為錨、其餘參照動態解析。如果沒有——凍結參照只能當一次性用途、跨操作的功能改走查詢。
3. 「不變」的出處是什麼？ 文件說的、程式碼推理的、實測證實的——只有第三種算數。把實測結果固化為測試資產（語意級假後端與流程測試、真實後端驗證測試），從此不依賴任何人的記憶。

三個問題的回答決定參照的設計形態。未回答就動工的代價是靜默失效——操作對著死 id 回寫，回傳值看起來正常（目標不存在也沒有噪音），功能在特定操作之後全部失效、直到使用者回報。凍結參照在測試中的結構盲區另見 T.C5：由測試餵資料的 stub 同時控制凍結值與回應資料，讓「id 死亡」這個狀態在測試裡不可能出現。

穩定身份為錨、解引用延後到使用時

第二題的答案若為「存在」，設計形態收斂為：持有穩定身份、其餘參照在使用時動態解析。

「reference by identity + 解引用時機延後」把「id → 實體」的解析從持有時延後到使用時，讓解析結果反映上游當前的真相。額外的韌性：即使身份轉移發生在本端不知情的時候（另一台裝置觸發合併），使用時解析照樣找到新家。

查無結果時退回凍結值，搭配存在性檢查兜底——穩定身份的值域（如 uuid）讓失效的凍結值只會被擋下、不會誤中別的資料。退路的成本是一次額外查詢；退路被命中的頻率反映的是同步的及時性——頻率高代表催同步的時機需要調整（見下節）。

第二題的答案若為「不存在」，凍結參照是唯一手段，但它的有效期等於上游不做重建操作的期間。有效期內凍結合法；跨越有效期的功能需要改走查詢路徑——以業務鍵（訂單號、合約號這類人為穩定的識別碼）重新定位，而非依賴上游的技術 id。

自持狀態與可導出狀態：遷移分工

上游身份轉移（合併、拆分）發生後，下游持有的多份「以上游 id 為 key」的狀態面臨遷移問題。遷移判準一個問題就夠：這份狀態消失後，能否單靠向上游重新查詢完整重建？

兩類狀態的程式碼形狀差異清楚：自持狀態有一個「身份轉移通知」的入口方法，且它是所有身份轉移操作的必經站；可導出狀態沒有任何遷移程式碼，只有既有的同步迴圈。

可導出狀態「等下一輪同步」的延遲若不可接受，正確的加速做法是催一次既有同步——走同一條同步路徑、只是提早跑。催同步與手工搬移的差異在於：催同步後資料來源仍然只有上游這一份，手工搬移會製造第二份——兩份資料的分岔只是時間問題。催同步時注意同步路徑內部的順序依賴（路徑內的過濾機制可能依賴某份前置資料的新鮮度），順序錯了催出來的是空結果。

自持狀態的每一份都是一筆負債，債主是所有會改變上游身份的操作。盤點自持狀態清單、逐項問「上游為什麼不保存這個」——若上游未來補上這份資料，自持狀態就能降級為投影，遷移程式碼隨之刪除。這個分類判準與 讀模型的升級判準 同構：讀模型問「讀的形狀還是聚合根的形狀」，這裡問「這份狀態的真相在誰手上」。

凍結快照的正當用途

凍結參照應消滅、活解析應取代——這條原則有一個明確的邊界：呈現歷史事實的快照是凍結的正當用途。

同一筆記錄可以同時包含兩種欄位。出事的案例往往是把「顯示用的凍結值」順手拿去做「回寫用的定位」——凍結值在這個用途下跨越了它的有效期，失效的時機由上游的重建行為決定、持有端察覺不到。凍結時機的判準在 entity 與 value object 的判準 與 狀態轉換與稽核軌跡 各自從身份語意和稽核面到達同一個結論：歷史記錄反映事件發生當下的世界。

判讀訊號

• 特定操作之後某些功能靜默失效（回寫目標不存在、查詢結果為空），且單元測試全綠——跨邊界參照的 id 可能已死亡。先確認上游操作的「保留 vs 重建」語意，再看持有端的解析時機。
• 修復 bug 只搬了一層 id、遺漏另一層——同一個業務動詞涉及多層資料（單據 + 明細 + 記錄），每層的重建行為要逐層實測、修復的完整性以層數計。
• 手工搬移的程式碼與同步邏輯在同一份可導出狀態上各寫一次——搬移是多餘的第二份資料來源，改成催一次同步。
• 同步催了卻拿到空結果——同步路徑有內部順序依賴（過濾器讀的前置資料還是舊的），催同步前先確保前置資料已更新。
• 自持狀態的數量持續增長——逐項問「上游為什麼不保存」，每消除一項就少一類遷移 bug。

下一步路由

• 身份語意的入口判準 → entity 與 value object 的判準
• 凍結與稽核的時間軸判準 → 狀態轉換與稽核軌跡
• 可導出狀態與讀模型的同構關係 → 讀模型的升級判準
• 凍結參照在測試中的結構盲區 → T.C5 凍結參照失效被 stub 遮蔽
• 假後端模擬重建行為 → 語意級假後端與流程測試
• 參照層的 case → 跨邊界參照的生命週期
• 遷移層的 case → 自持狀態與可導出狀態

觸發場景：POS App 前端有多個服務各自持有「以單據 id 為 key」的狀態——輪詢的差異比對基準、事件追蹤記錄、當前品項快照。後端合併兩張單據後，舊 id 全部作廢，這些狀態何去何從？ 疑問來源：最初的直覺是「全部搬家」——把每一份狀態的 key 都改成新 id。實作後發現有些搬了是白搬、有些不搬會出大事，差異在哪？ 整理目的：把「上游身份轉移時的前端狀態遷移」整理成一個二分判準：自持 vs 可導出。 本文邊界：讀側設計的完整階梯見 讀模型的升級判準。

1. 三份狀態、兩種命運

合併發生後，前端各服務持有的狀態逐一檢視：

判準一句話：這份狀態消失後，能不能單靠向上游重新查詢完整重建？ 能 → 可導出，讓同步機制自然收斂；不能 → 自持，身份轉移時必須主動遷移。

2. 兩個方向的分類錯誤

把自持誤當可導出（沒搬家）：差異比對基準等不到任何同步來拯救——上游根本沒有「你上次看到什麼」的資料。結果是功能級事故（重複列印、記錄失聯）。

把可導出誤當自持（多搬家）：對快照做手工搬移，短期看似加速對齊，實際引入了第二個資料來源——搬移邏輯與同步邏輯對同一份狀態各寫一次，兩者的分岔遲早出現。本案初版就搬了快照，後來發現搬進去的是舊內容（明細 id 還是死的），真正的新內容要等下一輪同步——手工搬移只製造了「看起來已對齊」的假象。

正確形態裡兩類狀態的程式碼形狀差異很清楚：自持狀態有一個「身份轉移通知」的入口方法；可導出狀態沒有任何遷移程式碼，只有既有的同步迴圈。

3. 加速對齊的正確位置：催一次同步，而不是代替同步

可導出狀態「等下一輪」的延遲若不可接受（本案：合併後使用者可能立刻取消品項，需要新明細 id），正確做法不是手工搬——是立即觸發一次同步。同一條同步路徑、只是提早跑。

這裡還埋著一個順序陷阱：同步路徑內部有依賴（輪詢用本地單據列表過濾資料），催同步之前要先讓依賴就緒（先同步列表、再刷新快照），否則催出來的是空結果、反而污染比對基準。「催同步」不是一個呼叫，是一小段有順序約束的編排——這個順序錯誤實際發生過，由流程測試首跑抓到（T.C6）。

4. 與讀模型階梯的關係

「可導出狀態」就是讀模型精神在前端的形態：它是上游真相的投影，正確性靠「可隨時重建」保證，而不是靠維護它的每一次增量修改都正確。判準也同構——讀模型的升級判準問「讀的形狀還是 aggregate（聚合根）的形狀」，這裡問「這份狀態的真相在誰手上」。真相在上游 → 投影化、別自持；真相只在本端 → 承認自持、為它設計完整的生命週期（包含身份轉移）。

長期方向：自持狀態越少越好。本案的追蹤記錄之所以必須自持，是因為上游不保存事件的處理進度——若上游未來補上這份資料，追蹤記錄就能降級為投影，「合併搬家」的程式碼隨之刪除。每一份自持狀態都是一筆負債，債主是所有會改變上游身份的操作。

5. 可複用的判準

1. 上游身份轉移時，對每份以上游 id 為 key 的狀態問：「消失後能否單靠重新查詢完整重建？」——能，不搬；不能，通知搬家。
2. 可導出狀態的加速對齊 = 催一次既有同步（注意內部順序依賴），不是另寫搬移邏輯。
3. 自持狀態要有明確的「身份轉移」入口，且它是所有身份轉移操作（合併、拆分）的必經站。
4. 盤點自持狀態清單、逐項問「上游為什麼不保存這個」——每消除一項，就少一類遷移 bug。

下一步

• 自持 vs 可導出的遷移判準（理論層）→ 跨邊界參照與狀態所有權
• 讀側階梯的理論層 → 讀模型的升級判準
• 身份轉移的參照層問題 → 跨邊界參照的生命週期
• 順序陷阱被抓到的過程 → T.C6 流程測試首跑抓到順序 bug