結構良好的架構

「Salesforce 結構良好的架構」為結構設計師提供共用原則的基礎,可讓他們在一段時間內做出協助解決方案成功的決策。其以五個支柱 (Trust、Reliability、Operational Excellence、Resource and Cost Optimization 和 Fairness) 為基礎,每個支柱都會抓住在解決方案生命週期每個階段的重要品質維度,從初始設計到長期營運和成長。

此架構涵蓋結構設計師今天面臨的現實:在受管理業務系統內共同作業的人類、工作人員和平台。安全但在負載中很脆弱的解決方案,或在決策中有效但不透明的解決方案,並非結構良好。這些五個支柱共同運作,以確保品質視為整體而非獨立關注的檢查清單。

結構設計師會在設計審查、權衡對話和持續管理期間,使用架構作為一致的透鏡。它並未指定單一正確回答。它會為您提供要詢問的正確問題、要考量的正確模式,以及可跨小組使用的常用詞彙。

「Salesforce 結構良好架構」是 Salesforce Platform 上所建立解決方案的結構品質意見指南。它會編碼原則、模式和權衡,以區分規模和適應的解決方案,以及在壓力下累積技術債務或失敗的解決方案。

架構由五個支柱組成。每個支柱都會定義品質的維度、說明核心設計原則、識別通用模式,並針對傳統平台功能與代理 AI 工作量提供明確的指引。這些支柱一起全面涵蓋在 Salesforce 上建立某些內容的意義。

此架構不是產品手冊或實作指南。這是一種結構決策架構,這是一種思考品質的方式,無論解決方案使用的雲端、功能或工具為何皆適用。

來自超大規模雲端提供者的產業架構提供寶貴的一般指引,但其主要是針對雲端基礎結構和營運考量所建立,例如虛擬機器、網路、儲存和運算。Salesforce 結構設計師面臨不同的限制與功能:具有管理員限制、在 Customer 360 中有數十年業務邏輯、複雜整合解決方案、陳述性自動化、中繼資料驅動組態和受管理共用模型的多重租戶平台。這些動作會以一般雲端指引無法解決的方式,打造每個結構決策。

轉換至獨立工作人員會帶來其他考量事項。理性和動作的工作人員會導入非決定性、可能性性推理和「循環中人類」的監視模式,而先前的架構原本未處理這些模式,儘管一般用途架構已開始透過專屬的 AI 透鏡擴展至此空間。Salesforce 結構良好架構透過統一透鏡來解決傳統平台結構與工作人員系統。

此架構適用於在 Salesforce 平台上負責結構品質的任何人:

• 設計新解決方案或擴充現有解決方案的 Salesforce 結構設計師
• 設定並保護執行這些解決方案之組織的 Salesforce 管理員
• 為小組建立標準與模式的 開發商機
• 針對平台最佳作法向客戶提供建議的 顧問和合作夥伴
• 建立和管理自發工作人員系統的 AI 和工作人員專家

不需要工作人員 AI 的先前專業知識。此架構可供所有結構設計師存取,同時為在自治系統邊界工作的人員提供深度。

沒有單一正確的讀取順序。根據您的角色和立即需求選擇:

• **如果您不熟悉架構:**閱讀此概觀文件結尾,然後探索與您目前專案最相關的支柱。
• **如果您要設計新解決方案:**從 Trust 與可靠性 (非可協商的基礎) 開始,然後處理 Operational Excellence (您將如何運作)、Resource and Cost Optimization (您將如何維護),以及 Fairness (您將如何確保其公平地為所有使用者提供服務)。
• **如果您要建立代理程式解決方案:**請先閱讀「工作人員企業概觀」,以取得全方位的工作人員結構指引。接著,針對基礎模式 (「共用責任模型」、管理員限制、監視工具、TCO 建模、無障礙標準) 閱讀核心支柱文件 (上方連結)。最後,針對每個品質維度上的工作人員特定重疊,參照「代理企業」支柱變體 (從每個支柱連結)。
• **如果您正在執行設計審查:**使用基本文件作為結構化檢閱檢查清單。設計良好的解決方案具有每個相關支柱中關鍵問題的明確回答。

最重要的結構決策涉及基本資料的權衡。架構可協助您明確說明以下內容:

• **信任與資源和成本最佳化:**加密與稽核記錄會耗用資源。架構可協助您識別 Trust 需求在何處為無法協商,以及您有彈性的位置。
• **可靠性與資源和成本最佳化:**可用性愈高,成本愈高。SLO 定義可協助您將投資與實際業務需求進行比對,而非預設為最大冗餘。
• **卓越營運與速度:**全方位可觀察性與測試需要一些時間才能實作。架構可協助您識別風險設定檔的最低可行觀察性。
• **公平與自治:**工作人員自主權愈高,可提升效率,但也會產生公平性風險。「循環」模式可協助您找到每個決策類型的正確平衡。

這些權衡沒有通用的答案。此架構可協助您提出正確的問題,並謹慎地進行權衡,而不是在生產環境中探索這些問題。

「結構良好架構」本身的設計會以以下原則為考量:

• **平台特定但技術不明確:**此指引會解決 Salesforce 特定的限制 (管理員限制、多重租戶結構、中繼資料驅動組態),而不會規定特定產品或功能。結構設計師可為其內容選擇正確的功能。
• **不含指示性的意見:**架構會清楚說明什麼是品質,但不會規定單一實作路徑。其提供原則、模式和問題,而非需求。
• **謹慎前瞻,同時遵守目前情況:**架構可解決新興模式 (原生 AI、自發系統),同時保持與傳統平台解決方案相關。這兩個使用個案都享有相同的基礎原則。
• **即時,非靜態:**架構會隨著平台、產業作法和客戶需求的變化而發展。「變更記錄」會追蹤更新,讓結構設計師能夠掌握最新新指引。
• **可在每個階段採取動作:**無論您是設計新解決方案、執行檢閱或改善現有實作,架構都會提供相關的指引。這不只是憑證檢查清單,也是工作工具。

這些原則可確保架構在各種結構環境中保持實用,同時維持關於結構品質對 Salesforce 解決方案有何意義的明確且一致的指引。

每個支柱都涵蓋建築品質的基本層面。這些支柱共同提供全方位涵蓋範圍—沒有單一支柱本身足夠,而支柱之間的權衡是最重要的結構決策所在。

以下五個支柱為傳統平台應用程式、整合和代理程式系統等所有 Salesforce 解決方案提供基礎結構指引。工作人員企業概觀及其伴隨的支柱變體提供工作人員特有的重疊資料:工作人員如何根據這些功能建立、系統何時自主運作的變更,以及受管理 AI 所需的結構模式。

同時使用兩者:

• 從核心結構模式的主要指引開始 (例如「共用責任模型」、管理員限制、監視工具、TCO 建模、無障礙標準)。
• 接著,針對工作人員特定的考量事項參照對應的「工作人員企業」支柱 (例如,工作人員權限和稽核鏈、協調失敗處理、工作人員開發生命週期、權杖最佳化、工作人員工作單位、可解釋性和可爭用性)。

這些支柱並非「傳統」與「真實」—這些支柱是代理解決方案所建立的基礎結構。工作人員系統必須滿足與任何其他企業解決方案相同的Trust、可靠性、卓越營運、資源和成本最佳化及公平性需求,並且額外考量自動作業。

此表格提供快速參考。以下為每個支柱的詳細指引。

透過現代安全性、最低權限存取權、隱私權控制和清晰的管治,保護您的解決方案、其資料和使用者。Trust on Salesforce 透過「共用責任模型」:作業Salesforce 會保護基礎結構與平台的安全,然後您會在基礎上建立安全解決方案。您的責任涵蓋:

• 身分與存取管理 (角色、設定檔、權限集、MFA、SSO、OAuth)
• 資料管理 (Shield Platform Encryption、物件/欄位/記錄級安全性)
• 整合安全性 (API 驗證、已命名認證)
• 安全開發作法 (適用於 Salesforce 的 OWASP 熱門 10 項、靜態分析、CI/CD 安全性門)

**針對工作人員解決方案:**當工作人員自主採取動作時,Trust 需求會延伸至管理允許工作人員執行的動作、稽核其所執行的動作,以及保護工作人員對平台的邊界 (Agent Fabric、Einstein Trust Layer)。請參閱 Agent Enterprise Trust。

若要深入瞭解,請參閱 Trust 支柱和 Agent Enterprise Trust。

針對連續可用性設計、在中斷後快速復原,以及在非預期需求下調整容量。可靠性需要瞭解平台保固 (多區域基礎結構、平台 SLA),同時設計在這些限制內保持可靠的解決方案。此支柱涵蓋:

• 管理員限制與 70% 營運上限指引
• 非同步處理模式 (批次 Apex、可排列 Apex、平台事件)
• 外部整合的斷路器
• 產能規劃
• 載入測試
• 多組織模式
• 災害復原
• 健康模式

**針對工作人員解決方案:**工作人員驅動的系統會導入可能性行為,其需要協調流程失敗的新模式、串聯工作人員錯誤的斷路器,以及決定性工作人員圖表,其中業務成果需要可預測性。請參閱「代理企業可靠性」。

若要深入瞭解,請參閱「可靠性」支柱和「代理企業可靠性」。

在您的解決方案中建立全方位可觀察性,並透過正確定義的程序和自動化來管理解決方案。「傑出作業」涵蓋:

• 可觀察性 (事件監視、Proactive Monitoring、規模中心)
• DevOps 作法 (來源驅動的開發、CI/CD 管道、測試策略)
• 自動化 (使用 Flow Builder 宣告優先,使用 Apex 程式設計模式)
• 事件管理 (嚴重性層級、通話輪換、無罪的死亡後計)
• 持續改善 (DORA 度量、營運審查)

**針對工作人員解決方案:**當系統行為為可能性時,可觀察性會變得較難。工作人員開發生命週期 (ADLC) 透過五個階段提供結構:計畫和設計、開發、測試和驗證 (包括工作人員測試中心對準確度、一致性和指示符合度的評估)、部署和發行,以及監視和調整 (包括 Agentforce 工作階段追蹤以取得端對端互動可見性)。請參閱「代理企業傑出作業」。

若要深入瞭解,請參閱「營運傑出」支柱和「工作人員企業傑出營運」。

透過有效利用您所擁有的內容,並謹慎地在購買的項目上進行投資,以傳回每美元和每個平台資源單位的最大業務價值。在資源方面,這表示瞭解管理員限制 (SOQL 查詢、DML 陳述式、堆疊大小、CPU 時間),並透過 SOQL 最佳化、非同步處理和防止資料誤差在內進行設計。在成本方面,這表示全面建模直接成本 (實作、營運、維護) 和間接成本 (技術債務、管治費用),通常會超過直接授權成本。此支柱涵蓋:

• 程式碼組織模式 (觸發處理常式、服務層級、選取器)
• 封裝與模組性 (受管理的 2GP 與「解除鎖定」封裝 (兩者皆為第二代封裝類型,LWC 組成)
• 資料週期管理 (封存策略、流程最佳化)
• 效能監視工具 (刻度中心、查詢計畫工具、ApexGuru、Salesforce Code Analyzer)
• 建立與購買分析 (AgentExchange 評估)
• 授權與 Sandbox 最佳化
• 成本監視與管治 (顯示面板、預算控制、顯示回傳與傳回模型)

**針對工作人員解決方案:**工作人員工作流程會複雜邏輯步驟、工具呼叫和資料提取之間的資源耗用,因此權杖用量、推斷延遲和記憶體模式需要最佳化。工作人員系統也會導入以耗用為基礎的成本 (「彈性信用」、推斷權杖),其比每位使用者授權更難預測。工作人員工作單位 (AWU) 會測量工作人員實際完成的工作 (已完成的離散工作),而非原始權杖耗用。請參閱 工作人員企業資源和成本最佳化。

若要深入瞭解,請參閱「資源和成本最佳化」 支柱和「工作人員企業資源和成本最佳化」。

確保您的解決方案可供存取、非歧視、包容和透明,並擁有適當的人力監督自動化決策。公平性以平台基礎為基礎。Salesforce Lightning Design System (SLDS) 提供標準元件的內建無障礙功能,而自訂元件需要明確的 WCAG 2.1 AA 實作 (針對新工作建議使用 WCAG 2.2 AA,這是 2024 年 12 月起的目前 W3C 建議)。此支柱涵蓋:

• 無障礙測試 (ax-core、sfdx 掃描器)
• 非歧視模式 (OWD、共用規則、使用 Shield 事件監視的 FLS)
• 隱私權結構 (Data 360 同意管理、欄位稽核追蹤)
• AI 道德管理 (檢閱板、公平權限門、法規合規性)。

**針對工作人員解決方案:**當工作人員做出影響人員的自主決策時,公平性的利益會增加。可解釋性 (瞭解工作人員採取動作的原因)、可爭議性 (挑戰性決策) 和「循環中人」 (比例監督) 變得十分重要。請參閱「代理企業公平性」。

若要深入瞭解,請參閱「公平」支柱和「代理企業公平」。

隔離中沒有任何資料欄。一個支柱中的結構決策會影響其他支柱:

• 更強大的 Trust 控制項 (加密、稽核記錄) 會耗用更多資源並增加成本 (資源和成本最佳化),並增加影響可靠性的延遲
• 更高的可靠性 (冗餘、多區域) 會增加成本 (資源和成本最佳化) 和營運複雜度 (卓越營運)
• 更全面的「公平性」強制執行 (人力監督、偏差監視) 會使工作人員的輸出速度變慢 (資源和成本最佳化)
• 更高的「傑出作業」成熟度 (全方位儀器) 可達成更佳的 Trust 強制執行和更早的「公平性」問題偵測

這些互動意味著結構品質一律保持平衡。架構可協助結構設計師瞭解其交易的內容,並刻意進行交易。目標不是同時最大化每個支柱,而是針對指定解決方案的需求、風險容忍度和業務內容,達成正確的品質設定檔。

分享您對良好架構的回饋意見。