結構模式
此頁面提供結構性疑慮的全方位模式指引,包括功能單位、疑慮分隔、狀態管理、API 管理和傳訊。這些模式會透過有關服務邊界、資料存取模式和元件責任的刻意設計決策,打造長期解決方案的成功。
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| Apex 類別 | ✅ 服務類別遵循單一責任原則,名稱明確指出用途 (AccountService、OrderProcessor、InventoryManager)。每個服務類別都專注於一個網域或業務功能。服務類別中的方法擁有 20 行以下的單一重點責任。 |
| 觸發 | ✅ 觸發會委派至處理常式類別,而非直接包含業務邏輯。觸發處理常式模式會依內容一致使用明確方法名稱 (handleBeforeInsert、handleAfterUpdate)。處理常式類別會透過每個方法具有單一責任的觸發事件來組織邏輯。 |
| Lightning Web 元件 | ✅ 元件遵循單一責任原則,並有明確的適用介面進行組態。每個 LWC 都專注於一個 UI 問題 (資料顯示、使用者輸入、瀏覽)。專為組成而設計的元件,而非單一實作。 |
| 服務層級 | ✅ 服務類別會壓縮無關進入點 (觸發、API、流程、批次) 的業務邏輯。相同的服務類別會處理多個叫用內容,而不會重複。服務層會將業務規則與呈現方式與資料存取權問題分開。 |
| 可重複使用元件 | ✅ 專為在多個專案和小組之間重複使用而設計的元件。使用自訂中繼資料類型的組態驅動行為會在不需要程式碼部署的情況下啟用行為變更。「可叫用動作」會將 Apex 邏輯顯示為可從「流程」和外部協調流程中使用的陳述性建構區塊。 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 神類別 | ⚡️ 避免在單一類別中累積過度的責任。將大型類別 (> 500 行) 分割成具有單一責任的焦點類別。當他們處理多個不相關的問題時重新組織類別 (OrderProcessor 不應同時處理電子郵件傳送與報告)。 |
| 混合疑慮 | ⚡️ 避免在單一類別中混合觸發邏輯、業務規則和資料存取。在控制項中將呈現邏輯與業務邏輯分開。將整合的疑慮與核心網域邏輯保持分開。 |
| 觸發邏輯 | ⚡️ 避免將業務邏輯直接內嵌在觸發檔案中。切勿將 300 個以上的條列觸發用於巢狀條件。一律透過明確的方法依觸發內容來委派至處理常式類別。 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 商業邏輯 | ✅ 業務規則集中在服務類別中,不分散在觸發、控制項和批次類別之間。無論記錄如何進入系統,網域類別都會一致壓縮記錄層級行為 (驗證、預設值、衍生的值)。邏輯會在服務層中重複使用,而非在整個進入點中重複使用。 |
| 資料存取權 | ✅ 儲存庫或選取器模式類別後移除的資料存取權。集中在選取器類別 (AccountSelector、OpportunitySelector) 中的 SOQL 查詢,可確保欄位清單和 WHERE 子句一致。存放庫模式可使用模擬資料來源進行測試,而無須變更業務邏輯。 |
| 介面契約 | ✅ 元件會透過明確的介面溝通,而非實作詳細資料。Apex 介面會定義圖層之間的契約。自訂中繼資料組態會定義行為邊界。「平台事件」提供產生者和消費者之間的傳訊契約。 |
| 模組邊界 | ✅ 繫結的內容會針對資料模型和業務規則定義明確的擁有權界限。每個模組都擁有其資料、自動化和業務邏輯。模組會透過定義的 API 互動,而非直接共用資料庫物件。文件會清楚識別哪些小組擁有哪些物件和服務。 |
| 相依性流程 | ✅ 相依性在單一方向流動 (簡報 → 業務 → 資料)。核心業務邏輯依賴外部任何項目,以啟用獨立的進化。基礎結構考量事項 (記錄、快取、外部 API) 取決於透過介面的商業邏輯,而非反之亦然。 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 邏輯重複 | ⚡️ 避免在觸發、API 端點和批次類別之間重複業務邏輯。在服務層集中並在整個進入點重複使用。每當相同的業務規則出現在多個類別中時,請將其解壓縮至共用服務。 |
| 散點資料存取權 | ⚡️ 避免透過不一致的欄位清單和 WHERE 子句,在觸發、控制項和批次類別中散佈 SOQL 查詢。在選取器類別中集中查詢,以確保一致的模式,並在單一位置啟用 LDV 最佳化。 |
| 觸發中的商業邏輯 | ⚡️ 避免驗證規則、欄位計算和工作流程協調流程直接內嵌在觸發程式碼中。移至服務類別或網域類別。將觸發保持精簡,僅專注於委派給適當的處理常式。 |
| 控制項中的業務邏輯 | ⚡️ 避免在 Aura/LWC 控制器方法中進行複雜的計算、驗證或資料操作。控制者應將通話協調至服務層,而非直接實作業務規則。 |
| 循環相依性 | ⚡️ 避免具有循環相依性的封裝或類別,其中 A 取決於 B,而 B 取決於 A。將共用疑慮解析為個別模組、反轉相依性方向,或使用以事件為導向的通訊來中斷配對。 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台快取 (組織分割) | ✅ 在組織分割中快取的頻繁存取參考資料,包括自訂中繼資料對應、選項清單值、組態設定,以及高成本作業的計算結果。根據資料波動性設定的預設 TTL (每月變更參考資料的小時數、經常更新的組態分鐘數)。快取金鑰策略可防止不同資料類型的衝突。 |
| 平台快取 (工作階段分割) | ✅ 使用者特定的偏好設定、計算的個人化資料,以及儲存在工作階段快取中的工作階段範圍狀態。工作階段快取不適用於應在使用者之間共用的資料。快取無效策略會適當地處理使用者偏好設定更新。 |
| Lightning 資料服務 | ✅ LDS 提供 Lightning Web 元件的自動用戶端記錄快取。標準 CRUD 作業使用 LDS,而非自訂 Apex 控制項。LDS 可消除冗餘的伺服器來回行程,並提供樂觀的 UI 更新。元件利用頁面上的共用 LDS 快取。 |
| 自訂中繼資料類型 | ✅ 儲存在自訂中繼資料類型中的組態和行為規則,而非在類別中硬式編碼。可透過變更集或來源驅動開發在環境之間部署的自訂中繼資料。變更自訂中繼資料不需要完整的部署週期。快取平台快取中的自訂中繼資料查詢以獲得效能。 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 迴圈中的查詢 | ⚡️ 避免在迭代迴圈內執行 SOQL。在迴圈外的單一 SOQL 陳述式中查詢所有必要記錄。依照父系識別碼將結果組織至 Maps,以在迭代期間進行對應。這是最常見的單一 Salesforce 防模式。 |
| 重複查詢 | ⚡️ 避免在每個交易中查詢相同的自訂中繼資料、自訂設定或參照資料多次。查詢一次,在平台快取或交易靜態變數中快取,在交易之間重複使用。 |
| 遺漏快取策略 | ⚡️ 避免在沒有快取的情況下重複查詢頻繁存取的參考資料。實作自訂中繼資料、組態和計算結果的平台快取。根據資料波動性定義適當的 TTL。 |
| 快取無效 | ⚡️ 避免快取資料,而不考慮無效策略。定義適當的快取 TTL 以更新頻率。當來源資料變更時,在僅 TTL 不足時實作手動快取清除。 |
| 未受管理工作階段狀態 | ⚡️ 避免假設工作階段狀態在未驗證的情況下持續在整個頁面瀏覽中。Lightning 元件應處理頁面載入時的狀態重新整理。使用 Lightning Data Service 進行自動狀態同步化。 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 解決方案結構規劃 | ✅ 結構規劃會在重大建立投資之前發生,包括需求分析 (功能與非功能)、預期資料量管理員限制分析、符合需求的模式選取,以及定義主要元件與介面的元件設計。 |
| 設計模式選取 | ✅ 一直套用經過驗證的 Salesforce 設計模式:業務邏輯重複使用的服務層模式、資料存取摘要的存放庫/選擇器模式、可互換演算法的策略模式、記錄層級行為的網域模式、一致觸發組織的觸發處理常式模式。 |
| 結構決策記錄 | ✅ 儲存在版本控制項中的 ADR 中記錄的重要結構決策。ADR 會捕捉內容 (業務驅動因素、技術限制)、決策 (選擇的項目)、考慮的替代項目 (其他人拒絕的原因),以及後果 (交易、技術債務、重新造訪觸發)。 |
| 建立與購買評估 | ✅ AppExchange 評估會使用擁有者總成本分析來排在自訂開發決策之前。評估條件包括策略價值 (競爭差異因素與商品)、TCO 比較 (建立工作、維護、升級成本)、整合複雜度,以及解決方案證明不足的結束成本。 |
| 管理員限制分析 | ✅ 結構規劃會識別哪些管理員會限制最嚴格的設計,以指定預期的資料量與交易模式。設計為在高峰狀況下耗用少於任何單一管理員限制 80% 的交易。為成長、未來功能和非預期使用模式建立的利潤。 |
| 風險評估 | ✅ 針對推送平台界限的結構方法所識別的技術風險。針對每個重要風險定義的緩解策略。原型或概念證明工作會在完整建立承諾之前,驗證高風險技術方法的假設。 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 無計畫 | ⚡️ 避免在未分析資料量、管理員限制影響或模式選取的情況下開始建立。結構規劃工作坊應在建立開始前識別主要限制、選取模式,並根據管理員限制進行驗證。 |
| 未記錄的決策 | ⚡️ 避免在會議中做出結構性決策,而無須瞭解內容、原因、替代項目和後果。使用儲存在版本中的「結構決策記錄」控制為未來小組成員保留決策內容。 |
| 無建立與購買分析 | ⚡️ 避免在沒有 AppExchange 評估的情況下建立自訂解決方案。在自訂開發之前評估前 3-5 個相關封裝。比較 TCO,包括實作工作、維護、升級成本和結束成本。 |
| 工程中 | ⚡️ 避免僅針對目前的資料量設計而不進行成長投影。預測資料成長達 2-3 年。根據目前容量 5–10 倍驗證的選擇性設計查詢模式。為成長建立結構利潤。 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 第二代受管理封裝 (2GP) | ✅ 2GP 用於需要命名空間隔離、AppExchange 散佈和 IP 保護的新受管理封裝。具有模組化應用程式開發的來源驅動開發工作流程。明確管理的封裝相依性。以語意版本化發行的版本。 |
| 解除鎖定的封裝 | ✅ 未鎖定的封裝,用於需要模組化且不含命名空間限制的內部企業應用程式。無組織相依性成品的封裝獨立部署。已追蹤適當部署順序的封裝相依性。為內部封裝定義的版本化策略。 |
| 模組邊界 | ✅ 清除為每個封裝定義的擁有權界限。每個封裝都擁有其資料模型、業務規則和自動化。封裝會透過定義的介面來互動,而非透過直接物件存取。文件會識別封裝擁有權與封裝間契約。 |