先記住：依變更原因分責任，不要只依行數拆檔。
需要深入時：再做模組邊界設計。

一個改金額格式的需求，竟然碰到付款邏輯

假設購物車元件有六百行：
抓資料、算折扣、讀取 Storage、發送追蹤事件與顯示畫面都放在一起。
AI 一次生成時很方便，但後來要改格式，卻得小心不要影響結帳。

這是變更原因混在一起的訊號。
單一職責不是一個函式只能一行，也不是每個檔案只能有一個方法；它提醒我們，把會因不同理由而變動的責任分開。

開搞前先盤點，再拆

我會先標出四類工作：
呈現資料、協調流程、處理業務規則、連接外部系統。

它們可能分成 UI、Use Case、領域函式與 Adapter，也可能只需要兩三個模組。
例如格式化金額跟 API 路徑沒有理由一起變。
驗證報價版本與畫面字體也不必相互依賴。
先找到這些穩定的邊界，再決定檔案名稱。

不要只把原本六百行搬成六個一百行檔案。
如果它們仍透過共享物件互相改資料，理解成本不見得下降。

用「改一件事，要讀幾個地方」判斷

原本更換報價服務，需要進元件修改請求、欄位與錯誤處理。
整理後，外部格式由 Adapter 處理，流程只知道取得有效報價或明確失敗，UI 負責呈現。
但這也有成本：多一個模組就多一個需要理解的介面。
若功能只有幾行純顯示，而且沒有多種變動來源，先保持簡單通常更合理。

好的拆分不是看抽象層數，而是讓最常發生的變動有明確落點。

重構先保護行為

開始拆之前，先記住成功、業務拒絕、逾時與草稿保留的既有行為。
已確認的缺陷可以修，但要明確列出；不要以重構名義順便改產品規則。

可以先抽出純格式化，再抽 API 邊界，最後整理流程狀態。
每一步可檢查、可回退，比一次全部改名更容易發現問題。

如果提取後測試變得需要啟動整個頁面才驗證一個計算，表示責任可能還沒切乾淨。
相反，測試若全在驗證私有函式呼叫順序，也可能綁得太深。

可以交給 AI 的 Prompt

請先分析這個購物車元件的變更原因，標出 UI、流程協調、純規則與外部 I/O。提出最少必要的拆分，每個新模組說明責任、輸入輸出與依賴。先保持行為和公開介面，分步重構；不要只依行數拆檔，也不要新增沒有需求支持的通用框架。

這段用的是 SRP (單一職責原則) 與模組邊界。
它要求 AI 解釋為什麼這裡值得分開，而不是機械套目錄模板。

今日練習與筆記

替一個大元件的每段邏輯寫下「它可能因為什麼改動」。
把理由相同的圈起來，再看看哪些內容其實不屬於 UI。

明天來嘗試使用 把 SOLID 轉成可執行的重構指令，然後我盡力特別說清楚依賴反轉到底反轉了什麼。
（想到反轉就會想到這張圖）