團隊做了一個統一入口。
使用者不用知道底下有多少不同 Interface,也不用先選 Specialist。
只要說:
「幫我找這台設備重新啟動管理服務的方式。」
Entry Agent 會先判斷 Target 和 Operation,再把工作交給對應 Specialist。
一開始效果很好。
後來為了讓回答更快,團隊把幾個常用操作也直接寫進 Router。
反正都是高頻問題。
這樣有些 Request 甚至不用 Handoff。
直到某天,使用者問同一個重啟操作。
Router 回了一組指令。
Specialist 如果真的被叫到,會回另一組。
兩邊都不是亂猜。
只是 Specialist 已經更新過 Platform-specific Rule,Router 裡那份「方便用」的知識沒有同步。
系統成功把 Request 分到正確 Domain。
卻在真正需要 Domain Knowledge 的地方,又自己做了一半。
建立統一入口時,很容易遇到一個誘惑:
既然 Router 已經知道這麼多,乾脆順便回答。
最初幾個 Case 看起來也很合理。
如果每次都要:
Entry
→ Specialist A
→ Specialist B
→ Specialist C
會讓架構看起來很碎。
所以大家開始往 Router 塞:
久了以後,Entry 不再只是 Entry。
它變成每個 Specialist 的縮小副本。
這時候真正的問題不是檔案變大。
而是 Ownership 開始重疊。
Package 裡的邊界很簡單:
Router owns classification. Specialist owns domain execution knowledge.
Router 負責理解:
Target 是什麼?
Operation 是什麼?
使用者有沒有明確指定 Interface?
應該交給哪個 Specialist?
真正的 Domain Rule 則留在 Specialist。
假設某個操作規則變了。
如果只存在 Specialist:
Update specialist rule
就結束。
如果 Router 也保存一份:
Update specialist rule
Update router shortcut
Update documentation
Check fallback copy
而且任何一份漏掉,系統就可能根據 Routing Path 回出不同答案。
這種錯誤不一定馬上被發現。
因為兩份答案在一段時間內都可能「曾經是對的」。
所以 Entry / Specialist 分層真正要保護的不是架構美感。
而是讓一條 Domain Rule 有清楚的 Owner。
分層不是單向限制。
Specialist 不應因為自己知道某個 Domain,就開始接所有相近問題。
當 Request 超出 Scope,它應該 Handoff。
例如一個 Specialist 負責 Interface A。
使用者實際問的是另一種 Interface。
如果 Specialist 看到關鍵字很像就硬回答,結果一樣會漂。
所以兩邊各自只守一件事:
Router
→ Which capability owns this request?
Specialist
→ Within my scope, what is the correct domain answer / action contract?
那次不一致之後,團隊沒有新增同步機制去維護兩份 Command Table。
反而把 Router 裡那些 Domain Detail 拿掉。
Entry 只保留:
intent classification
initial routing
handoff context
真正的操作、限制、驗證方式回到 Specialist。
下一次同樣的 Request 進來:
我要重新啟動管理服務
Router 沒有回答指令。
它只做了一件事:
這是 Interface B 的 restart operation,交給 B Specialist。
Specialist 再根據自己的最新 Source 回覆。
多了一次 Handoff。
卻少了一份需要永遠跟著更新的影子知識。
從那天開始,Router 還是知道該找誰。
只是它終於不再假裝自己也要知道每個人到底怎麼做。