從 Reactive Graph 回到 Architecture Boundary

Day24~25 的驗證得到三個結果：

1. Reactive Graph 沒變：Computed、Watch、Render 等工作量相同。
2. Depth 20 Update 變快：Application Timing −21.2%，Scripting −25.6%，兩組數據方向一致。
3. Runtime Attribution 證據不足：目前無法確認這 −25.6% 有多少來自 Vue Runtime。

因此這次實驗無法把改善直接歸因給 Vue Framework，但它反而讓另一個工程問題更值得處理：

當 Reactive Graph 的複雜度來自我們自己的 Architecture，AI Coding 要怎麼避免把它繼續放大？

AI 很容易把「可以拆」變成「應該拆」

假設 Component 裡只有一段搜尋邏輯：

const search = ref('')

const filteredUsers = computed(() =>
  users.value.filter(user =>
    user.name.includes(search.value)
  )
)

AI 很容易進一步整理成：

Component
 ├─ useSearch()
 ├─ useUsers()
 └─ useFilteredUsers()

程式碼看起來更有結構，但多了幾個檔案，並不代表 Architecture 就更好。

真正需要觀察的是：

State
  ↓
Dependency
  ↓
Computed / Watch
  ↓
Effect
  ↓
Update

Composable 只是程式碼的 Boundary；一旦裡面建立了 ref、computed、watch 或其他 Reactive Effect，就可能同時改變 Reactive Graph 與 Update Path。

因此判斷抽象是否合理時，不能只看檔案結構。

先問：這個 Boundary 為什麼存在？

有些 Composable 本身就代表完整的行為，例如：

usePagination()
useFormValidation()
useWebSocket()

它們通常具備明確的責任、Lifecycle 或 Side Effect，也可能在不同地方重複使用；相反地，如果只是把同一個 Domain 硬切成：

useUser()
   ↓
useUserState()
   ↓
useUserData()
   ↓
useUserComputed()

此時可以用四個問題判斷這些 Boundary 的必要性：

1. 它代表什麼 Boundary？

   是 Domain、Lifecycle、Side Effect，還是單純把幾行程式碼搬到另一個檔案？

2. 它真的會被 Reuse 嗎？

   只使用一次的邏輯，不需要因為存在共用的可能性就提前抽象。

3. 它有自己的責任嗎？

   如果 Composable 只是轉接，就要確認這層是否提供了新的語意或真正的封裝價值。

   const state = useState()
   
   return {
     value: computed(() => state.value)
   }
   

4. 它增加了多少 Reactive Relationship？

   例如原本：

   state
     ↓
   computed
   

   抽象後變成：

   state
     ↓
   composable
     ↓
   composable
     ↓
   computed
     ↓
   watch
   

   這時候改變的已經不只是 Code Structure，Reactive Graph 變複雜，Update Path 也可能跟著變長。

把這些檢查交給 AI

與其要求 AI 大量建立 Composable，可以直接把 Boundary 檢查寫進 Coding Rule。

Before creating a new composable, explain:

1. What boundary does it represent?
2. Why should this boundary exist?
3. Is the logic actually reused?
4. Does it introduce additional reactive relationships?
5. Can the behavior remain local without losing clarity?

If the boundary has no clear reason to exist,
keep the logic local.

這個 Rule 的目的很直接：

需求
 ↓
AI 建議抽象
 ↓
Boundary Review
 ├─ 有明確責任 → 建立 Composable
 └─ 沒有明確責任 → 保留 Local Logic

這跟前面的 Component Explosion 有相同的檢查方向： 先確認 Boundary，再增加結構。

Component 與 Composable，都在建立 Boundary

把前幾天的實驗放在一起，可以看到兩種不同的 Architecture Boundary：

Component
   │
   │ Render Boundary
   ↓
Render Tree

Composable
   │
   │ Logic / Reactive Boundary
   ↓
Reactive Graph

Component 主要決定 UI 如何拆分、哪些內容一起 Render。

Composable 主要決定 Logic 與 Reactive Dependency 如何組合。

兩者都有合理的使用情境，也都可能因為 Boundary 過多，讓系統增加額外的結構與關係。

所以 AI Coding 時，真正需要限制的不是 Component 或 Composable 的數量，是對於 每增加一個 Boundary，都要有可以說明的理由。

這也是今天想建立的基本規則：

可以拆
  ↓
為什麼要拆？
  ↓
Boundary 是否有明確責任？
  ↓
是否值得增加這層結構？

小結

這次 Composable 實驗中，Vue 3.6.0-rc.2 的 Scripting 減少了 25.6%，但目前的 Runtime Attribution 證據不足，還不能把這項改善直接歸因給 Vue Runtime。

因此，Framework 的改善與 Architecture 的設計需要分開驗證，對 AI Coding 來說，可以先建立「**有明確 Boundary，再建立抽象」**規則。

到了這裡，我們處理的是 Logic / Reactive Boundary，下一個問題就變成：

如果 AI 看得到元件，卻看不到整個產品的 Design System Boundary，會產生什麼問題？