"Clean-Architecture"
- 4.1 事件來源、處理流程與狀態邊界
分辨事件來源、事件融合、處理流程、狀態真相與推送邊界
- 4.3 Source of Truth：狀態邊界
集中狀態更新、保護可變資料、設計查詢 projection
- 一行查詢放哪、一個測試留不留：結構改動後的兩次「還需要存在嗎」
修完一個應收金額 bug 收尾時，兩個『還需不需要』的問題浮出來。一段『過濾出已結帳品項』的查詢該掛哪一層——inline 在 widget 是洩漏、開一個 service 是儀式，判準是『查詢誰擁有的資料就掛給誰』，答案是既有的 repository。一個為了鎖住修復而寫的測試該不該留——當修復是靠刪掉舊函式、移除參數達成時，那個 bug 被結構免疫了，測試變贅述；判準是『這測試守的失敗模式，結構是否已經替它擋掉』。
- 兩個 domain 各自實作同一個 API service — 100% 覆蓋率的假象
同名 service 在多個 domain 各自實作時，覆蓋率數字會失去意義：每份實作各測各的、mock 各有介面，統一的行為從未被測過。重複實作是上游訊號——規劃文件沒抽出跨 domain 的共同技術需求；單檔品質審查看不到跨檔重複。
- BDD 測試：測行為，不測實作細節
替換一個實作就要跟著改掉大批測試、而業務邏輯根本沒動時，用來判斷哪一層該用 Given-When-Then、Mock 的邊界畫在哪裡
- 行為優先的 TDD：測試耦合行為、不耦合結構
重構時測試大量壞掉、或在「該不該 mock 這個協作者」上需要一個可執行的立場時，本站對兩派 TDD 分歧的選擇與推導
- 架構合規交給機制，不交給自律
分層架構在文件上完整、而 codebase 三個月後依賴方向已經走樣時，用來把架構規則轉成 commit 前就會擋下來的自動檢查
- 混合測試策略：根據架構層級選擇測試方法
全面單元測試讓重構成本失控、而只測重點又說不出業務邏輯對不對時，用來按架構層決定每一層該用哪種測試
- 層級隔離：讓每張 Ticket 只做一件層級的事
PR 一次動了四層、review 無從下手時，用來把 Clean Architecture 的分層轉成 Ticket 的拆法與執行順序