概念位置

不變式跟輸入驗證的責任不同。不變式守「這個物件能不能存在」——違反時物件不該被建出來；輸入驗證守「使用者輸入對不對」——違反時要好好告訴使用者。兩者混放會讓格式驗證塞進建構子、或存在條件放進 validator。不變式跟 snapshot 有交集——歷史 snapshot 凍結的是過去規則下合法的狀態、回讀時不一定通過新規則的不變式。

可觀察訊號

型別上出現「請用某方法修改」「此欄位勿直接改」的註解時，不變式已經到場、強制還停在文件層。建構子或方法的 throw / assert 是不變式在執行層工作的證據；grep 得到零個對應檢查時，是宣稱約束但未強制。

設計責任

同一條不變式可以落在文件層（註解）、型別層（介面簽名）或執行層（建構子檢查），層次決定違反時發生什麼——靜默通過、編譯失敗、當場拒絕。選擇依違反代價與建置成本折算。教學層展開見 不變式的強制層次。

概念位置

Entity 是領域模型的一種形態——型別先判定為領域模型（有不變式）、再判定身份語意（entity 或 value object）。判準是「操作需不需要 identity-based 回寫」：取消、改量、退貨這類要精確指到特定實體的操作，需要 entity；內容比對就足夠的操作用 value object。同一個業務概念的身份語意會隨生命週期階段改變——每個轉折點重問一次判準。

可觀察訊號

改量、取消這類操作用內容比對定位對象——同內容的其他實體會被誤中，這是模型該升級成 entity 的訊號。entity 的變更路徑通常經由領域方法——如果 entity 同時有領域方法與全開放的覆寫工具，變更路徑正在退化。

設計責任

Entity 需要決定身份的來源（資料庫序號、外部系統 ID、業務規則產生的識別碼）、生命週期的階段（何時誕生、何時交棒、何時成為歷史事實需要 snapshot）、以及變更的路徑（領域方法的設計，見 狀態轉換與稽核軌跡）。判準的完整展開見 entity 與 value object 的判準。

概念位置

Value object 有兩個獨立的價值。第一個跟 entity 的判準有關——操作以內容為對象（累加、合併、比對、替換）就用 value object。第二個是語意封閉：把一個領域概念的合法運算限縮成封閉集合——差集裡的每個運算都是等著被誤用的 API。語意封閉的價值獨立於同一性判定、也獨立於容器型別的類別——資料袋裡照樣可以放語意封閉的 value object。

可觀察訊號

一個領域概念以裸的通用型別跨模組流通（金額是 double、識別碼是 string）、而它的合法運算遠少於底層型別——語意封閉的價值已成立。封裝後要給原始值一個語意明確的官方出口（見 建構路徑設計）。

設計責任

Value object 需要決定相等性定義（哪些欄位參與比對、參與本身就是業務規則）、不可變策略、以及封裝出口。枚舉是 value object 的一種——粒度判準看消費者需求、不看分類系統本身。判準的完整展開見 entity 與 value object 的判準。

概念位置

聚合根是本模組尚未展開的章節主題（模組 backlog）。目前在教學章中以例子形態出現：一個 POS 專案的商品從扁平結構長成雙層聚合——商品作為聚合根、規格作為子層——欄位歸屬的判準是「兩個規格會不會不同」（資料袋與領域模型）。聚合的邊界跟 entity 的生命週期邊界是兩個獨立的設計決策。

可觀察訊號

多個物件的修改必須一起成功或一起失敗、而這些物件目前散在不同的存取路徑——缺少聚合根把它們收在同一個一致性邊界裡。

設計責任

聚合根的邊界劃太大會把不相關的物件鎖在同一個事務、限制併發；劃太小會讓跨聚合的一致性問題推到應用層。邊界的判準是「哪些不變式必須在同一次操作內成立」。完整教學等 case 累積後展開。

概念位置

資料袋跟領域模型是型別類別的兩端。判準是「有沒有不允許任意組合的欄位」——有就是領域模型、沒有就是資料袋。資料袋裡照樣可以放語意封閉的 value object（如 Money）；容器的類別判定跟欄位的封閉性是正交的兩條軸。資料袋可以隨業務演進升級成領域模型——升級時機由演化訊號決定、而非預測。

可觀察訊號

型別的每個欄位都可以獨立修改且不影響其餘欄位的語意——資料袋。型別上出現「請用某方法修改」的註解但欄位仍全部 public 可寫——判定可能錯了、讀 資料袋與領域模型 重新檢視。

設計責任

資料袋加上領域模型的儀式（工廠、私有建構、變更方法）只會製造沒有規則可守的 boilerplate。判斷準則是「這個型別有沒有需要強制的規則」——沒有就不要建領域模型。完整判準見 資料袋與領域模型。

概念位置

Snapshot 跟 entity 的生命週期有關——概念成為歷史事實之後、live 內容參照要凍結。凍結的同時身份參照通常繼續承重（退貨鍵、取消鍵）。Snapshot 也是稽核的端點——記錄事件發生當下的世界、而不是現在的世界（見 狀態轉換與稽核軌跡）。

可觀察訊號

歷史記錄的顯示內容跟著現行資料變動（商品改名、訂單明細跟著變）——參照凍結時機漏掉了。進行中的資料不跟著最新狀態走（購物車品項的價格不跟會員身分變動）——凍結太早。

設計責任

凍結時機由業務對「過去」的要求決定——進行中的操作持 live 參照是正確的、成為事實之後凍結。業務流程有多個確認階段時、凍結時機取決於哪個階段之後的漂移對下游不可接受。凍結判準的完整展開見 entity 與 value object 的判準。

概念位置

port 跟一般 interface 的差別在歸屬與語言：宣告在領域層、以領域概念命名（BookRepository 而非 SqliteClient）、方法簽名只用領域型別。介面本身是型別層的約束載體——它強制了「呼叫方看不見技術細節」，與 invariant 的型別層強制同一個機制。

可觀察訊號

介面檔案位於 domain 目錄、簽名沒有框架型別，是 port 健康的訊號。介面裡出現 DatabaseConnection、HttpClient 這類技術型別時，port 已被實作細節滲透——呼叫方被迫認識它不該認識的層。

設計責任

port 定義「領域需要什麼」，不保證「有人供給它」——宣告了介面、沒有實作被插上，在 mock 測試裡不會有任何紅燈。供給的驗證屬組裝層，教學層展開見 組裝層的可達性。port 的歸屬判準（逐型別問「這是誰的詞彙」）在 reactive 場景的完整推導見 觀測出口的職責三分。

概念位置

adapter 有兩側。driven adapter 被領域呼叫（資料庫、外部服務的實作）；driving adapter 呼叫領域（UI 事件處理、API handler）。兩側的共同責任是翻譯：領域語言與技術語言在這裡互換、不讓任何一邊的詞彙滲到對面。adapter 對外接的介面是 port、兩者插上的位置是 composition root。

可觀察訊號

實作類 import 框架套件、以技術命名（SqliteBookRepository），是 adapter 各安其位的訊號。領域規則出現在 adapter 裡（折扣計算寫在 repository、狀態判斷寫在 handler）是反向滲透——規則離開了領域模型、invariant 的強制位置跟著失守。

設計責任

adapter 寫完、測試通過，只證明它自己行為正確；它有沒有被插上 port、插的是不是它，是組裝層的問題。接線的證言與強制層選擇見 組裝層的可達性。adapter 作為變更偵測機制的具體歸屬案例（寫入點 emit vs 儲存層 hook 的選型）見 觀測出口的職責三分。

概念位置

composition root 是組裝層的核心、不是組裝層的全部：路由表以單點註冊靠攏它，UI 事件的接線散佈在各畫面——位置不同、同屬組裝層的責任。組裝層守「正確的路徑走得通」，與 invariant 守「違反的路徑走不通」互為對偶。

可觀察訊號

具體型別的建構與註冊集中在一處，是組裝責任歸位的訊號。new 語句散落各層、或 provider 停在佔位 throw「requires override」，是組裝責任洩漏或組裝未完成——後者在 mock 測試下全綠、只有無 override 的解析會暴露。

設計責任

組裝有沒有完成，在以 mock 為基礎的測試套件裡沒有證言；補證言的接線測試、可達性作為不變式的強制層選擇，教學層展開見 組裝層的可達性。

概念位置

DI 容器是框架提供的註冊與解析機制、把「哪個介面對應哪個實作」收成一份註冊表：啟動時註冊、使用時解析——每一條可解析的註冊項就是一個注入項、部分生態稱它 provider。注入的集中點是 composition root：全部具體型別在這裡被決定。測試框架的 override 機制（用替身蓋過註冊項）是 DI 給測試的 seam。

可觀察訊號

建構子收介面、具體實作的選擇集中在組裝處，是注入責任歸位的訊號。類別內部直接建構自己的依賴（new 具體型別、呼叫全域單例）時、該依賴在測試裡換不掉、技術選擇散落各層。

設計責任

注入讓「誰提供真實作」成為一個獨立責任。這個責任有沒有被履行——每個注入項在無 override 環境解析得了——在行為測試裡沒有證言（綠燈證明不了它）、要由 接線測試 驗證；教學層展開見 組裝層的可達性。

概念位置

seam 是分層架構測試承諾的兌現機制：「domain 可以脫離 infrastructure 測試」的具體操作、就是在 seam 換上替身。DI 容器的 override（測試用替身蓋過註冊項）是 seam 的容器化形式；composition root 集中的組裝、正是 seam 替換的對象。

可觀察訊號

測試不碰 production 程式碼就能把資料庫、網路、時鐘換成替身，是 seam 工作中的訊號。想測某段邏輯必須連上真實服務、或得修改本體才塞得進替身，是 seam 缺席的訊號。

設計責任

seam 有一體兩面：替換掉的正是 production 的組裝、於是「組裝有沒有完成」在以 seam 為基礎的測試裡沒有證言（綠燈證明不了組裝完成）。mock 測試全綠與功能可用之間的缺口由 接線測試 補；這道影子的完整推導見 組裝層的可達性。

概念位置

一個測試通過時能證明的事（本模組 稱「證言」）由執行環境決定：在 test seam 換上 mock 之後、綠燈對組裝再無證明力，接線測試因此是測試層面組裝證言的唯一來源（編譯期生成組裝碼的生態、編譯器先接住「缺實作」一類，其餘仍歸這裡）。跟端對端測試的分工是範圍換速度：E2E 在目標平台連行為一起驗、接線測試只驗接線，換取在 host 環境（開發機、非目標裝置）快速且確定地執行。

可觀察訊號

個別測試用 override 是正當的 seam 用法；訊號要看專案層級——連一個零 override 的解析測試都沒有時、組裝處於無人作證的狀態。

設計責任

零 override 的邊界是組裝路徑：domain 到入口之間不替換任何一段、最外圈的 infrastructure（遠端服務這類）可以在邊界替換。回傳假值的 佔位 解析得了、導航也會發生、在接線測試眼中是正常構件，要靠行為斷言或發版冒煙走查。這條界線在應用程式層怎麼守、組裝層的可達性 有完整推導。

概念位置

失效的靜默程度比文件層約束（層次判準見 invariant）再深一級：文件層失效至少留下「規則寫在那裡、沒人遵守」的對照證據；佔位讓測試綠燈——型別層看它是合法構件、行為測試的 override 讓它永遠沒被觸發（override 的機制見 test seam）。

可觀察訊號

佔位頁的型別名、「requires override」的拋出語句、空函式體都是靜態可掃描的形態。回傳假值的佔位在掃描與 接線測試 眼中都是正常構件——注入項解析得了、導航也會發生。

設計責任

佔位需要一個獨立的攔截點：靜態可掃描的形態進發版前置檢查、掃到即警告、由人判斷是刻意中間態還是漏網；回傳假值的那一類靠行為斷言或實機冒煙走查。攔截點怎麼落進發版流程、組裝層的可達性 有完整處置。

概念位置

read model 是 CQRS 讀寫分離的讀側，與 aggregate root 的寫側形成互補：aggregate 守一致性邊界、read model 服務讀的形狀。它的存在不以 CQRS 全套為前提——讀側是一道階梯：消費端自行投影、讀 port 抽離（獨立的 port）、專用投影、事件同步的獨立儲存，每一階都是 read model 概念的某種深度。低階的 read model 可以只是 ViewModel 裡幾行 map；高階的 read model 有自己的儲存與更新節奏，接受與寫側的最終一致性。階梯橫跨 ephemeral（ViewModel 內聯投影，沒有獨立生命週期）到 durable（獨立儲存、事件同步），但各階共享同一個設計責任——「讀的形狀由讀需求定義、不由 aggregate 形狀決定」——因此視為同一概念的深度變體。

可觀察訊號

repository 介面長出回傳統計值、分頁切片、反正規化投影的方法，是讀的形狀開始混進 aggregate 介面的訊號。反向的訊號同樣可觀察：還沒有第二條讀需求就先建投影層，抽象沒有消費者、每個新查詢多穿一層介面。

設計責任

read model 定義「讀側要什麼形狀」，升級到哪一階由訊號決定、不由架構偏好決定——五個升級訊號（讀需求增生、形狀偏離、負載分歧、新鮮度分級、獨立演進）與階梯各階的代價，教學層展開見 讀模型的升級判準。

概念位置

domain event 是 aggregate root 執行業務操作後的副產品——aggregate 保證一致性、event 把「剛才發生的事」通知外界。event 的消費者是跨 domain 流程、審計、通知等「需要知道發生了什麼」的角色。它跟 read model 在 CQRS 第四階交會：讀模型由事件同步時，消費者問的確實是「發生了什麼」（用事實重建投影），這是 event 的合法消費。

可觀察訊號

event 被借用成 UI 刷新訊號時會出現四個判讀訊號：為了讓某頁刷新而補發事件、監聽端掛全事件過濾器、移除事件前要查有沒有畫面靠它刷新、event payload 開始塞當前完整狀態。任一出現，回到載體判準重新選——消費者問「現在是什麼」時，正確載體是狀態流。

設計責任

domain event 記錄業務事實、服務審計與跨 domain 通訊。event 的發布時機由業務語意決定（「這件事值得記錄、有下游需要它」），涵蓋面是業務事實的集合——跟狀態流的涵蓋面（寫入操作的集合，結構性涵蓋）正交。載體選用判準、案例演進與判讀訊號展開在 domain event 與狀態流；事件對命令與查詢的責任結構分界展開在 domain event 與命令、查詢。命名的過去式約定展開在 Domain Event 命名的過去式。

概念位置

狀態流是 觀測出口 的載體形態：觀測出口定義「資料變了、我能告訴你」這個能力歸屬哪一層、狀態流定義這個通知的語意——連續快照、不是離散事實。它的涵蓋面是寫入操作的集合：emit 掛在每個寫入方法尾端、新路徑必然經過、涵蓋不靠任何人記得發——與 domain event「業務語意決定發布點、逐事實設計」的涵蓋方式正交。

可觀察訊號

系統缺狀態流出口時，補償的形狀是訊號：導航返回點出現手動 reload、為了讓某頁刷新而補發事件、監聽端掛全事件過濾器。事件被誤用成狀態流的完整判讀訊號表在 domain event 與狀態流。

設計責任

狀態流承擔「畫面、快取、衍生視圖對資料當前值的觀測」，錯過的代價為零是它跟 event 不可互換的原因——需要逐筆事實（審計、下游流程）的消費者拿快照會斷檔。載體選用判準展開見 domain event 與狀態流、實作選型（broadcast、初始值、dispose）見 StreamProvider 包 repository watch stream。

概念位置

觀測出口的契約層是一種 port：簽名只用語言標準庫與 domain entity、放 domain repository 介面，與 pull 方法形成對稱。機制層（broadcast controller、寫入點 emit）歸 adapter；組裝層（框架 provider 包裝）歸 DI／presentation。三層歸屬的完整判準與「需求來源不決定歸屬」的推導見 觀測出口的職責三分。

可觀察訊號

repository 缺觀測出口時，每個衍生視圖各自解「怎麼知道資料變了」：導航返回點補 reload、EventBus 橋接刷新、多個視圖各自維護 load 時機。補償策略的交叉與涵蓋缺口是這個能力該補的訊號。

設計責任

觀測出口讓「資料變更」成為可訂閱的一級節點，涵蓋面等於寫入操作的集合——emit 掛在寫入方法尾端、新路徑自動涵蓋。它通知「現在是什麼」、不記錄「發生了什麼」——後者是 domain event 的責任，兩者正交。落地的實作點（broadcast、初始值、dispose）見 StreamProvider 包 repository watch stream。

概念位置

repository 預設是 pull 介面：呼叫端主動問「現在的資料長怎樣」，一次拿到一份 aggregate 形狀的答案。它不天生具備「資料變了通知我」的推送能力——這條能力屬於 observation outlet，是 repository 介面之上的另一層職責，需要另外設計才會出現。

可觀察訊號

repository 介面開始長出 getMonthlyStatistics()、searchWithPagination() 這類回傳統計值或反正規化形狀的方法，是讀的形狀混進 aggregate 介面的訊號——查詢集合已經大到值得思考該不該抽獨立的讀側介面，量測與升級路徑見 讀模型的升級判準。

設計責任

repository 的設計責任是守住 aggregate 一致性邊界的存取入口，不是最佳化每一種讀需求的效能與形狀——後者是 read model 的責任。repository 是否該同時扛下變更通知，判準不是「需求來自誰」而是介面用什麼語言表達，完整推導見 觀測出口的職責三分。

概念位置

單一 bounded context 內的架構判準，跨過邊界不必然照搬。讀模型升級的四階梯（消費端投影 → 抽讀 port → 專用投影 → 事件同步的獨立儲存）假設操作發生在單一 bounded context 內；報表服務訂閱多個 domain 的事件建置共享視圖，是跨 bounded context 的讀模型，這時引入的關注點——跨服務事件契約穩定性、schema 演進、跨信任邊界的最終一致性——不是「多買一種能力」能概括，完整推導見 讀模型的升級判準。這類跨邊界溝通的常見載體是 domain event，其中攜帶足量狀態給下游的作法見 event-carried state transfer。

可觀察訊號

一個判準句在單一服務內成立、換到跨服務場景就開始要補額外的機制（契約版本、schema 遷移、補償流程），是踩到 bounded context 邊界的訊號——原本的判準沒有錯，是它的適用範圍被劃在邊界內，邊界外要重新論證。

設計責任

bounded context 的設計責任是替模型畫出「在哪裡可以直接假設一致」的邊界，邊界外的互動改走顯式的契約與轉換，不能沿用邊界內的內部語意。這條邊界也是判斷同一套架構結論能不能套用的分界——邊界內成立的推導，邊界外要重新論證，不是預設繼續有效。

概念位置

EventBus 是 domain event 的傳輸機制、不是事件本身：event 是「發生了什麼」的事實記錄，EventBus 是讓這個事實從發布端跑到訂閱端的管道。EventBus 只解決「怎麼送達」，送達之後訂閱端該把事件當事實通知還是當變更信號來用，是另一個判準，見 domain event 與狀態流。

可觀察訊號

訂閱端掛上「監聽全部事件、任何事件進來就重新查詢」這種全事件過濾器，是把 EventBus 兼職成變更通知管道的訊號——這條路徑上線初期有效，但涵蓋面等於「有沒有人記得發事件」，跟寫入操作的集合不天然相等，多個視圖各自解「怎麼知道資料變了」時容易補出交叉且不完整的補償策略。

設計責任

EventBus 只承擔「發布／訂閱」這一層機制、不承擔涵蓋保證——涵蓋是靠每個寫入路徑記得呼叫 publish 換來的，EventBus 本身不驗證有沒有漏發。需要涵蓋面天然等於寫入操作集合的場景，正確載體是 observation outlet 的狀態流、不是把 EventBus 的監聽範圍擴大，完整案例見 觀測出口的職責三分。

概念位置

CQRS 是一道讀側設計階梯的頂端、而非二選一的開關。讀側的設計從「消費端自行投影 aggregate 形狀」開始，中間經過「抽獨立讀 port」「查詢形狀專用投影」，到頂端才是 CQRS 全套——讀寫獨立儲存、由 domain event 同步讀模型。多數專案的正確位置在階梯低處、不是頂端，升級由訊號驅動而非架構偏好。

可觀察訊號

讀寫分離的討論從「查詢方法該不該搬出 repository」，逐漸變成「讀模型需不需要自己的儲存、能不能接受跟寫側短暫不一致」，是逼近階梯頂端的訊號——第四階的代價是最終一致性進入系統語意，畫面可能短暫顯示舊值，而這是設計內行為，不是 bug。

設計責任

要不要上 CQRS 全套，不看「這個模式聽起來很適合」，看五個具體訊號（讀需求增生、形狀偏離、負載分歧、新鮮度分級、獨立演進）是否命中——本卡只回答「CQRS 是什麼、階梯怎麼分階」，訊號的完整推導與升級路徑是 讀模型的升級判準 這篇的內容，要判斷自己的專案該停在哪一階、讀那篇。

概念位置

這個設計只在跨服務、跨信任邊界的情境下成立。同進程情境下，事件開始攜帶全量狀態通常是載體錯位的訊號——消費者真正要問的是「現在是什麼」，正確載體是 state stream 而非塞胖的事件；跨服務時「回頭查詢來源」本身有同步耦合的成本，event-carried state transfer 用胖 payload 換掉這個成本，是同一個訊號在不同信任邊界下的相反判讀，完整推導見 domain event 與狀態流。

可觀察訊號

事件的 payload 從「哪本書、什麼時間」這類事實欄位，長出「現在的全貌」這類當前狀態欄位，是判讀的觸發點；判讀不看 payload 胖不胖，看消費者是不是跟事件來源在同一個信任邊界——邊界內是錯位、邊界外是正當設計。

設計責任

event-carried state transfer 換來的是下游服務不必為了拿到完整資訊而同步呼叫來源，代價是事件 payload 的 schema 跟著狀態演進、下游要一起處理相容性。這個代價只有在真的省下跨服務同步查詢時才划算，同進程情境沒有這筆成本可省，應優先考慮 state stream。

概念位置

共享可變狀態的代價不在讀寫本身，在於它會長出跨函式的時序約束：「這個值必須活過那一次重設」「A 要在 B 清空之前讀完」。這類約束是 invariant 的一種，但落點的處境不同——單一物件的不變式可以做進建構子或型別簽名，跨函式的時序約束在型別簽名裡沒有位置、建構子也檢查不到，剩下的落點只有一條會紅的測試（強制層的取捨見 不變式的強制層次）。

把值收成呼叫時傳入的參數，可見範圍縮到那一次呼叫，約束就不存在了。所以遇到這類約束時的第一個問題是「這個值需不需要共享」，而不是「誰來守這個順序」。

可被觀察不等於可被寫入。一個值要讓畫面訂閱（state stream 的形態）是讀側需求，跟「誰改得動它」是兩個獨立的決定。兩者被同一個欄位承擔時，「因為畫面要看所以只好共享」會被誤當成「所以也只好開放多方寫入」。

可觀察訊號

註解出現「重設時不要清掉這個值」「先讀再清」這類順序叮嚀時，共享可變狀態已經長出時序約束，而強制還停在文件層。測試要先擺好某個欄位才跑得起來、而那個欄位不在被測函式的參數列裡，是同一個訊號的測試側形態。同一個欄位的寫入點散在多個控制器或服務時，「當前值是誰寫的」已經無法從單一位置回答。

設計責任

先問這個值需不需要共享——能收成參數就消除整組約束，不需要任何一層守它。必須共享時把寫入點收斂到單一路徑（讀可以開放、寫要有唯一入口），並把「可觀察」與「可寫入」分開設計。約束消不掉時，交給一條會紅的行為測試，而不是交給一行叮嚀順序的註解——判準與當場可執行的驗證見 #253 寫註解的動機是怕被改壞時要處理的是那個約束。