今日主題：

就像全班要一起拼一幅「大拼貼畫」。

• 小明用彩色紙
• 小華用布
• 小美用亮片

每個作品都很漂亮，但要拼在同一張大海報上時，可能會掉下來或卡不住。
在程式裡，這種情況就叫做 「元件衝突」。不是不能合作，而是需要找到共同的規則，才能順利拼在一起。

ADP：依賴方向原則 (Acyclic Dependencies Principle)

意思：不要有「繞圈圈」的依賴。
生活比喻：
想像你在班上要傳便條紙。
如果 A 同學要傳給 B，B 又要傳給 C，結果最後 C 又要傳回 A，那大家就會卡住，變成一個圈圈，傳不出去。
ADP 就是提醒我們：傳便條紙（依賴）不能繞回來，要單方向。

SDP：穩定依賴原則 (Stable Dependencies Principle)

意思：越重要、越不容易改的東西，要放在底層，其他人依賴它才安全。
生活比喻：
蓋房子時，地基要最穩定，大家才能蓋在上面。
你不會讓整棟房子放在一個會搖晃的桌子上吧？
程式也是這樣，大家都要依賴「穩定」的元件，才不會常常大亂。

SAP：穩定抽象原則 (Stable Abstractions Principle)

意思：越穩定的東西，要盡量是「規則」而不是「細節」。
生活比喻：
像學校規定「每天要排隊進教室」，這個規則很穩定，不太會改。
但是「誰今天當排頭」可以換。
所以穩定的部分要抽象成規則，不要鎖死在小細節。

在程式設計裡，元件就像是積木，每一塊都有自己的功能。
但有時候，當我們把不同的元件組合在一起時，會發現它們不一定能完全搭配，這就是「元件衝突」。

在元件的依賴關系圖中不允許出現環。

範例故事：

想像一下，你和同學要一起拼一座大城堡。
小明拿來的積木比較大，小華拿來的積木比較小。
當你們拼在一起時，會發現有些地方卡不上，或是拼好後不穩。
這就是因為大家的積木不一樣，不能完全無縫接合。

在程式中的應用是什麼？

要開始慢慢調整後端的結構了。

在電腦程式裡，不同的元件可能是由不同的人寫的。
有的人用 A 方法設計，有的人用 B 方法設計。
雖然大家都想把它們組合在一起，但因為規格不完全相同，就可能出現錯誤或無法運作的情況。
程式設計師需要花時間「調整」或「轉換」才能讓它們協同合作。

今天改善了 Middleware 和橫切關注點
為什麼：
驗證、速率限制、錯誤轉換、日誌、追蹤…屬跨越所有路由的「橫切關注點」。
放在 middleware，讓 Controller 專心轉發請求/回應。

[Vue 前端]  →  [Controller (Presentation)]  →  [Usecase (Business Rules)]
                                          ↙                 ↘
                                   [Repository]         [AiProvider]
                                   (Supabase/Memory)    (OpenAI/Gemini/Self-hosted)

變動快：Vue/Controller/外部供應商 → 用抽象與注入隔離
變動慢：Usecase（規則） → 盡量保持穩定、可測

小結與一個思考問題：

世界上沒有「完全完美」的元件，就像現實生活裡沒有完全相同的積木。
我們能做的，是盡量遵守規則，讓元件之間更容易配合。

思考問題：

如果今天要做一個「多人寫作的網站」，我要怎麼讓每一個不同的作者各自需要的元件（例如：遊戲化 Doodle、科技、Life Hack ）能順利拼在一起呢？

書本內容抄錄：
Clean Architecture 自上而下的設計裡面提到：元件依賴關係圖與描述應用程式的功能關係並不大。相反的，元件依賴關聯圖其實是應用程式可建制性(buildability)和可維護性（maintainability）的映射圖。這就是為何無法在專案開始時設計出他們的原因。**因為沒有軟體要被建置或維護，所以不需要建置或維護的映射圖。**但隨著在實作和設計的初期所累積的模組越來越多，未避免專案開發出現「隔天早上症候群＊」，對依賴關係進行管理的需求就會不斷增長。此外，我們也想盡可能保持變更的局部化，所以我們開始關係 SRP 和 CCP ，並把可能會一起變化的類別放在一起。

依賴結構的首要考慮之一就是隔離『易變性』。我們不希望頻繁變化的元件以及變化無常的因素，影響了其他原本應該穩定的元件。