核心原因：系統隔離與風險控制
客戶現有後台屬於核心內部系統，直接開放接口給外包團隊意味著：
- 安全風險：需暴露數據庫結構、業務邏輯、甚至源代碼給外部人員。
- 耦合風險：外包 APP 需求變更頻繁，若直接改動核心後台，極易引發線上故障。
- 職責邊界：外包合同通常只交付「APP + 其專屬後台」，核心系統維護由甲方內部團隊負責。
- 技術異構：核心系統可能是 Java/.NET 單體架構，APP 後台更適合 Node.js/Go 微服務，快速迭代。
典型架構演進
【舊模式】APP → 直接調用核心後台 RPC/HTTP 接口
問題：權限難控、改動牽一髮動全身、外包人員需高權限
【新模式】APP → 專屬 BFF (Backend for Frontend) → 核心後台內部 API
優勢：
1. BFF 由外包全權控制，技術棟自由選型
2. 核心後台僅暴露內部服務接口，權限最小化
3. BFF 做聚合、轉換、降級、限流，保護核心系統穩定
4. 交付驗收清晰：APP+BFF 為一包，核心系統不在驗收範圍
甲方視角的額外考量
- 數據所有權：核心數據不出庫，BFF 只調用內部服務獲取必要字段。
- 合規審計：金融/醫療行業要求嚴格審計，隔離層便於合規。
- 並行開發：外包團隊可獨立開發 BFF+APP，不阻塞核心團隊迭代。
- 驗收標準：驗收文檔針對 APP+BFF 接口契約，避免牽扯核心系統變更。
外包團隊應如何應對？
- 主動提出 BFF 方案，體現專業度與安全意識。
- 設計 接口契約文檔（OpenAPI/Swagger），雙方確認後並行開發。
- 提供 Mock 服務，APP 端開發不依賴核心環境。
- 交付時包含 部署腳本、監控告警、文檔，降低甲方維護成本。
總結
「另建後台」非多此一舉，而是企業級系統集成的最佳實踐。它以少量冗餘換取安全隔離、架構解耦、交付清晰，是成熟甲方與專業外包的共識選擇。
