Aggregate-Root on Tarragon

Aggregate Root

Fri, 10 Jul 2026 00:00:00 +0800

聚合根是對外代表一組資料一致性的邊界物件。外部操作只跟聚合根互動、不直接碰內部的 entity 或 value object；聚合根負責保證邊界內所有不變式在每次操作結束時成立。一致性的範圍就是聚合的邊界——邊界內是同一個事務、邊界外是最終一致。

概念位置

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

可觀察訊號

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

設計責任

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

Repository

Mon, 20 Jul 2026 00:00:00 +0800

repository 把「怎麼存、怎麼查」包裝成領域語言的介面：呼叫端看到的是存書、查書這類操作，看不到底層是資料庫、檔案還是記憶體。它是一種 port——依賴方向朝內、簽名只用領域型別——差別在 repository 專職 aggregate root 的存取。repository 回傳的形狀是 aggregate 的形狀（entity 或 entity 集合），這條界線是它跟 read model 分工的起點。

概念位置

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

可觀察訊號

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

設計責任

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

Bounded Context

Mon, 20 Jul 2026 00:00:00 +0800

bounded context 是一個模型與詞彙維持一致的邊界：邊界內，同一個詞（例如「訂單」）只有一種意義、同一套業務規則統一適用；跨過邊界，同一個詞可能換了意義、規則跟著換。aggregate root 守的一致性邊界在單一 aggregate 內；bounded context 守的是更大一層——一整套模型、詞彙與規則在哪裡開始、哪裡結束。

概念位置

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

可觀察訊號

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

設計責任

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