在此閱讀我們的更新排程。

可組合解決方案可快速調整且更穩定。建構為可組合的系統會以有意義的單位 (或建構區塊) 建立,這些單元可以彼此順暢運作,且可以輕鬆地交換為不在服務中。將可組合性建立在系統中,可讓您透過重新建構或重新組合系統的個別單位來導入新功能或移除技術債務。可組合性可啟用更快、更可預測的傳送週期和發行,因為小組可以透過更少的變更專注於建立和提供有意義的功能。

可組合系統可讓企業更快速且更穩定地適應,無論是業務內部或由外部因素所導致的刺激。可組合性可協助系統提高彈性,並有助於使解決方案和結構模式更具意圖。

您可以透過建立三個關鍵習慣,讓 Salesforce 解決方案更容易組合:關注分隔、互通性和封裝性。您可以在下方以兩種方式查看這些習慣的關係:針對可組合系統中的單一單位,以及可組合系統中的多個單位。

單一可組合單元:

可組合系統:

軟體工程和系統結構的一個基本概念,關注分隔需要在可分割成模組單位的大型系統內識別各種關注。若要在系統內強大區分關注,則需要在整個系統中為應用程式邏輯和功能建立有意義的單位。較小的單位可讓應用程式傳送與維護小組更輕鬆地瞭解如何和何處進行變更,同時對較大系統造成最少的中斷。較小的單位也可讓您更清楚瞭解處理技術債務時要專注的工作方式和位置,並為系統的整體可讀性做出貢獻。

您可以透過引導業務能力與管理狀態,在 Salesforce 組織中建立更完善的關注分隔。

針對 Salesforce 系統,區隔疑慮的最佳方法是套用以業務為導向的觀點,以識別和組織系統內的模組化單位 (或功能)。這與以工程為中心的檢視不同,其會根據其技術功能來識別單位。分隔關注的業務導向透視圖需要根據其為公司和業務使用者提供的服務,在系統中組織程式碼和自訂項目。採取此方法並不意味著忽略系統中冗餘或重複技術功能的潛力。相反地,這表示技術服務會明確對應至對業務而言最終為透明的組織原則。

以業務功能為導向,可協助確保業務分析與探索小組與遞送小組之間的轉移盡可能簡單。如果應用程式產生器不知道其工作單位在何處對應至您的可組合結構,則表示您處於混亂狀態,而非可組合應用程式橫向。公司所需的結束狀態與組織內模組化單位之間不清楚的對應也會增加開發小組或廠商將冗餘功能建立到系統中的可能性。

請考量下列事項以將功能單位引導至業務能力:

• 從待完成的工作開始。專注於使用者和業務本身的待完成工作 (JTBD)。由 Tony Ulwick 領導,JTBD 方法著重於瞭解人員使用產品或服務嘗試完成的「工作」或「真實目的」。這是比使用者角色相關工作或業務流程中個別步驟更高的抽象層級。例如,如重複檢查和地址驗證等工作可能屬於「建立客戶單一檢視」的較高層級功能。在您清楚瞭解這些高階業務功能後,可以開始將系統的部分對應至這些功能。
• 指向功能,而非報告結構。業務單位的內部階層並非要完成有意義的功能或工作的 Proxy。您業務的內部階層對流程和小組結構 (不包括預算) 具有重大影響。這些是重要的物流考量事項。但業務的功能需求運作的抽象程度高於物流。如果您要建立一個模組來提供報告結構,而非更高階的函數,請注意,您可能必須採取其他步驟來識別該模組與業務功能之間的關係。
• 重複。從與公司合作開始,以找出哪些功能可以用於最低可行產品 (MVP)。當您識別功能時,請開始建立該 MVP。當您建立時,請識別您正在建立的功能單位中關鍵的程序、中繼資料和 事件或訊息。識別任何屬於外部相依性的程序、中繼資料和事件或訊息。隨著設計更具功能的單位,請實作 API 管理和 相依性管理,以建立相互相容的單位 (而非建立隔離單位)。

以下的模式與反模式清單顯示 Salesforce 解決方案中對業務功能的正確 (和不良) 方向呈現的外觀。您可以使用這些功能在建立之前驗證您的設計,或識別需要重新設計的系統區域。

若要深入瞭解 Salesforce 提供的工具,以協助您進一步掌握業務功能,請參閱與可編輯功能相關的 工具。

州/省管理專注於整個系統在不同時間點的資訊移動。有效的狀態管理可讓應用程式處理複雜的資料流程或互動,其中最少有非預定或未確定成果。在模組化 Salesforce 組織中管理狀態意味著建立單位內和單位之間邏輯流程的明確路徑,以及針對非預定執行行為建立豐富的路徑。州/省管理可讓您從模組化 Salesforce 應用程式單元中建立一致的邏輯串流。在大多數的情況下,這需要可互通性來建構單位之間的資訊流程。

跨寬鬆連接單位管理狀態的困難通常會導致 Salesforce 中的單一應用程式開發。您可以在大型「單一流程」中看見,這是在嘗試在單一流程中協調複雜流程時建立的。另一個範例是大量 Apex 類別,可透過 Spaghetti 程式碼協調複雜程序,或一系列長的單一方法。這些類型的應用程式結構會使重新設定和除錯變得難以執行,並增加新小組成員或廠商的上線時間。它們也會降低提供給業務之應用程式的價值,因為功能無法重複使用。

請考量下列事項來管理整個模組化 Salesforce 組織的狀態:

• 決定何時使用狀態模式與無狀態模式。狀態模式會在整個執行路徑中保留資訊,無狀態模式則不會。在寬鬆連接的系統中,無狀態模式可讓元件更快速地重新產生,並減少副作用。不過,無狀態模式不適用於所有使用個案。如果您要建立資料作業的元件,則狀態模式有助於確保整個系統的資料完整性和一致性。如果您的元件符合下列任一條件,請使用狀態模式:
  • 瞭解在較大執行路徑內的放置位置對元件行為至關重要
  • 元件的行為必須根據下游動作的結果變更 (例如,它需要根據下游元件的回復/錯誤/成功訊息變更執行)
  • 元件需要等待外部或下游系統的回應,才能完成其工作
• 為狀態資訊建立有意義的種類。狀態是一個不明確的詞彙,可套用至 Salesforce 組織內 (及外部) 中如此深厚且廣泛的資訊陣列,這詞彙本身幾乎沒有意義。因此,建立狀態模式的必要第一步是為系統中最重要的狀態執行路徑 (或狀態行為類型) 建立具有意義的種類。考量一些種類:
  • 瀏覽與表單
  • 資料庫作業
  • 批次和大量作業
  • 錯誤
• 以資料 庫交易定義資料相關狀態。平台的內建行為會限定 Salesforce 中大多數資料的州考量事項。請勿嘗試對此行為進行管理或排除。為其設計與使用。設計最小化或消除散佈交易邏輯的解決方案。(如需詳細資料,請參閱 資料處理)。
• 識別在 (及跨) 功能單位中發生的狀態。當您將功能單位組合至較大的系統時,請注意當您混合無狀態與狀態元件行為時,並避免組合可能在處理中產生無限迴圈或間隙。
• 定義轉介。考慮元件會使用哪些傳訊或撤銷模式將狀態相關資料傳輸至系統的其他部分。確定您正在建立交易認知並在元件中進行處理。請勿在您的轉送中包含任何散佈的交易邏輯。
• 建立流程圖與狀態之間的對應。流程圖詳細說明在不同時間點透過系統移動資訊的步驟。狀態圖顯示資訊 (狀態) 中的實際變更。使用「Salesforce 圖表」 形狀的中繼資料頁尾部分,在流程的每個步驟之內捕捉資訊的變更狀態。如果您將流程圖與狀態圖分開,請務必將其連結。此概念在設計和實作期間,不應混淆於將流程或系統橫向的目前狀態和未來狀態記錄,因為這與系統中移動的資訊無關。

下方的 模式與反模式清單顯示 Salesforce 解決方案內的適當 (與不良) 狀態管理外觀。您可以在建立之前使用這些項目來驗證您的設計,或識別系統中需要重新設計的位置。

若要深入瞭解用於管理狀態的 Salesforce 工具,請參閱與可編譯相關的 工具。

下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。

✨ 在「模式與反模式探索器」中探索更多關注分隔的模式。

在針對互通性所設計的系統中,元件可以交換資訊並有效運作。互通性是使模組化系統可組合而非隔離的關鍵。在寬鬆連接的系統中,難以達成互通性。您需要為一致的整合方法建立標準,這不會損害單位之間的獨立性和整體系統中的整體關注分隔。

互通性也會影響使用者體驗的品質。您的使用者預期在一個區域中建立的資料 (例如訂單資訊) 可在另一個區域中使用 (例如行銷活動),而您的產生器預期,如果他們學習如何執行某些動作 (例如建立流程或驗證 API),則在繼續進行下一個問題時,他們會發現熟悉的技術可用。無法針對互通性設計,會導致結構冗餘、資料複製、流程效率不佳,以及開發和支援成本增加。

您可以透過傳訊和事件,以及透過 API 管理,在模組化系統中建立互通性。

訊息與事件是您在整個系統中啟用元件以傳送和接收資訊的兩種方式。在他們可攜帶的內容方面,事件與訊息類似。重要差異是寄件者的行為。傳送 訊息的元件通常會將資料傳送至特定目的地,並等待來自收件者的某種回應。相反地,當發生某些情況時,元件會發出一個 事件。沒有特定目的地,也沒有回應的預期。這些行為差異支援不同的通訊模式。訊息支援狀態通訊模式,而事件支援無狀態通訊模式。(如需有關此區別的詳細資訊,請參閱 州管理。)

在通訊協定上讓小組保持一致,並使用個案進行傳訊和事件處理十分重要。不明確的標準可能會導致整個系統混合模式,進而導致:

• 將錯誤的模式套用至特定使用個案的效能與延展性問題
• 不一致的處理,讓一般使用者看起來系統不穩定
• 更長的疑難排解時間與更複雜的維護流程

設計訊息和事件時,請考量下列事項,以在您的 Salesforce 組織內建立更寬鬆的連接結構:

• 識別同步和非同步使用個案。撤銷允許在整個系統中進行寬鬆連接、無狀態和非同步的通訊。「傳訊」允許更嚴格控制的狀態和同步的通訊模式。決定何時使用訊息或事件時,您需要決定您的通訊是否需要同步 (且可能會封鎖) 與非同步且非封鎖。
• 仔細定義資料結構。元件在元件之間傳遞的資訊結構是保持寬鬆連接系統可管理且一致性的重要部分。(如需詳細資訊,請參閱 API 管理。)設計訊息或事件時,關鍵考量事項是資訊結構可能需要變更的頻率。一旦在系統中定義並實作訊息或事件結構後,可能會難以處理更新,特別是當事件或訊息已用於將資訊傳送至外部系統時。
• 大小正確的訊息。一般而言,最佳作法是將訊息大小保持小。但是,訊息大小與訊息量之間也有平衡動作。系統可以更快處理較少量的資料。由於收件者必須解壓縮包裝、解譯並決定要如何處理收到的資訊,因此處理動作會帶來額外的負擔。這些步驟可能需要很少的時間完成,但可能會對大規模的系統產生負擔。避免設計需要系統中的元件來連續處理許多小訊息,以完成工作。若要正確調整訊息大小,請考慮針對下游元件所需的最小資料設計,以成功處理已傳送的資訊並採取行動,而不考慮每個下游元件都能夠要求或處理許多後續訊息。
• 設計可擴展性。寬鬆的元件可讓您更輕鬆地調整結構。去除跨元件相依性可讓小組致力於改善任何個別元件的效能或延展性,並對其他元件造成最小影響。不過,寬鬆連接的元件也會在大規模的結構中帶來顯著的複雜度 (尤其是當涉及到 管理狀態時)。針對有效的使用者體驗或資料完整性原因,識別需要更緊密地配對邏輯或相依性的程序,而不要嘗試將非同步/以事件為基礎的模式導入這些程序。改用以同步化/訊息為基礎的模式和正確的錯誤處理。

下方的 模式與反模式清單顯示 Salesforce 解決方案內的正確 (與不良) 傳訊與事件外觀。您可以在建立之前使用這些項目來驗證您的設計,或識別系統中需要重新設計的位置。

若要深入瞭解 Salesforce 傳訊和撤銷工具,請參閱與可編譯相關的 工具。如需為指定的使用個案選擇事件模式或工具的詳細資訊,請參閱使用 Salesforce 進行事件驅動結構的 結構設計師指南。

在 Salesforce 解決方案內建立適當的應用程式程式設計介面 (API) 管理,可讓系統的個別元件遵循可預測的通訊模式。Salesforce 提供內建的安全 API,用於與 Salesforce 外部系統通訊。(如需 Salesforce Platform API 的詳細資訊,請參閱 結構基本概念。)

Salesforce 解決方案中的有效 API 管理是建立真正可組合結構的關鍵。它可讓 Salesforce 組織內部的元件有效率地傳送和接收資訊。其也可讓解決方案產生器遵循明確的通訊協定,以瞭解其建立的元件如何與系統中的其他元件通訊,並協助其及早識別不良的實作。此外,其可讓解決方案產生器更專注於他們正在建立或重新建立的特定元件,進而提升生產力與品質。

企業層級的 API 管理是個別的主題,最適用於全方位的 API 管理工具。(如需有關此主題的更多 MuleSoft 觀點,請參閱「什麼是 API 管理?」)

請考量下列事項以在您的 Salesforce 解決方案內建立 API 管理功能:

• 將 API 視為通訊的可預測模式或契約。輸入或輸出變數的資料類型、變數名稱、應 (或不應) 以指定模式顯示的資訊—這是有效 API 管理的關鍵。這些定義應顯示在您的設計標準中,且小組應能夠透過您的文件瞭解這些定義如何在系統的特定部分中實作。檢視難以將新開發變更合併至整合環境的難題之一,就是將這些難題視為 API 通訊實作不良的證據 (或可能完全沒有 API 定義)。

• 不要將您對 API 的思考限制為只撰寫程式碼。在此情況下定義 API 的因素是訊息結構與變數在該訊息中的一致性。只要維持該一致性,API 即可在程式碼中以及陳述性自訂中 (例如模組式自動啟動 (或平台事件觸發) 流程,或甚至流程範本中進行實作。讓您的決定以程式碼與流程中要定義的內容為基礎,而不是以 API 實作為基礎,而是以 封裝可用性和 可測試性為基礎。

• 讓生命週期與版本化保持簡單。如同應用程式開發的所有部分,API 都有生命週期:定義、建立、測試、部署和維護 (包括淘汰)。Salesforce Platform API 會在一個行事曆年度內發行數個版本,因為平台的發行週期快速。(您可以在 Salesforce 結構基本概念中深入瞭解此行為。)這表示平台 API 的生命週期相當複雜,因為特定 API 的多個版本必須維護且可供 Salesforce 客戶使用。此級別的複雜度適用於 PaaS 使用個案,但對於平台上的解決方案結構而言,這可能是不必要的複雜度 (請參閱:可讀性反模式)。專注於為 API 定義清楚的目的 (例如,錯誤處理),並清除基準定義。盡量只有一個版本的每個 API。

• 讓您的 API 可供探索、存取和管理。記錄您的 API,讓潛在客戶可以輕鬆找到可用的 API 以與其連線。API 必須以流暢運作方式作為整合的 功能一部分。

• 重複。專注於一次僅定義和實作一個內部 API。如此一來,您就可以專注於快速重複 API 定義、尋找適合您的一個支援版本的表單,並從實作經驗中建立最佳作法。

下方的 模式與反模式清單顯示 Salesforce 解決方案內的適當 (與不良) API 管理外觀。您可以使用這些功能在建立之前驗證您的設計,或識別需要重新設計的系統區域。

若要深入瞭解 Salesforce 提供的工具,以協助您建立更大的互通性,請參閱與可編輯功能相關的 工具。

下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。

✨ 在「模式與反模式探索器」中探索更多可互通性的模式。

在 Salesforce 組織中建立封裝性表示組織中的功能來自可獨立且可靠地作為封裝開發和部署的單位。理想情況下,這些單位會定義為 第二代封裝類型 (ISV 的解除鎖定封裝或受管理封裝)。注意:由於設計良好的解決方案只會使用這些封裝類型,因此此處不會涵蓋第一代受管理封裝。

在 Salesforce 組織中定義關注分隔並建立功能單位是一件事。若要夠清楚地解析和管理相依性,以成功將這些單位版本化為封裝成品,則是另一個事項。若要達到該等級的穩定性和中繼資料隔離,則需要高層級的 DevOps (和結構) 成熟度。其也可加速開發時間、改善應用程式產生器體驗,並為版本與版本管理帶來可預測性和控制能力。並非每個組織都能夠支援定義、維護和開發有效封裝所需的基礎結構。但實現封裝性應該是幾乎每個 Salesforce 組織的最終目標。

您可以透過專注於寬鬆配對和相依性管理,在 Salesforce 解決方案中建立封裝性。

在寬鬆連接的系統中,個別組件不會彼此緊密繫結。可組合系統的許多優點來自於寬鬆連接。在可封裝的系統中,實現封裝 (與安裝組織) 之間的寬鬆連接可讓您擁有正確定義的封裝,並為使用封裝的小組提供更具生產力的開發週期。

在 Salesforce Platform 上,您可以建立緊密連接至特定組織的封裝。此功能對於定義功能單位,並針對在組織中正確分隔疑慮進行實驗很有幫助,因為您在封裝成熟度中取得進度。不過,如果您選擇此方法,您將會意識到真正可封裝中繼資料的幾個優點,包括來源驅動的開發、使用版本化和成品穩定性的能力。相反地,您可能會繼續遇到緊密連接系統的缺點,包括:

• 造成中斷和效能問題的單一失敗點
• 緩慢且無法預測的部署
• 困難、複雜的除錯和疑難排解週期
• 具有 規模與 效能的問題

任何可封裝 Salesforce 系統的最終目標為寬鬆配對的封裝。

當您將 Salesforce 中繼資料分成有效封裝時,請考量下列事項:

• 哪些自訂項目是資料與中繼資料。當涉及封裝性時,Salesforce Platform 會以不同的方式處理資料與中繼資料。請務必瞭解貴組織中哪些功能是 中繼資料或資料。您無法在任何封裝單位中包含資料。當您決定要從何處開始將功能解壓縮至封裝單元時,您的小組將需要決定儲存為資料的自訂項目是否應完全從封裝中排除,或重新定義為以中繼資料為基礎的實作。
• 封裝會如何影響小組。Salesforce 封裝的物流實際現實是,生產和發行封裝版本的大部分工作都需要具備 Salesforce CLI 和/或 CI/CD 技術的技能。這表示低程式碼和程式設計自訂項目都需要能夠使用封裝相關 DevOps 技術的人員花費時間和注意。根據您的小組管理功能傳送的方式,封裝採用可能會對整個組織的不同小組造成明顯的緩慢或封鎖。您必須識別小組是否能夠透過封裝管理功能傳送,並制定計畫以解決任何技能或員工缺口。解決方案可能包括針對開發環境採用配對的程式設計或實作 CI/CD 工作。
• 封裝如何改變環境策略。在封裝驅動的開發生命週期中,應在 臨時組織中提早完成工作。這些暫時的來源驅動開發環境允許更快速、更反覆的週期。它們也支援對開發小組進行更精確的環境存取控制,並與生產環境有更大的隔離。您的封裝對僅存在於 Sandbox 或生產環境中未封裝中繼資料或資料的相依性愈多,小組實際使用臨時組織的可能性愈低。您可以在 Sandbox 中啟用來源追蹤,以允許在非臨時組織環境中使用來源驅動的開發模式,但您的開發小組不會從臨時組織的速度和反覆速度中獲益。
• 封裝版本與版本之間的關係。計畫開發封裝版本化的發生頻率和階段。封裝版本要求限制為 24 小時輪動 (每個組織)。作為一般最佳作法,只有在您確信沒有任何封裝內容需要變更時,才能版本封裝。在理想情況下,您會在品質保證流程完成後佈建封裝版本。請勿讓開發小組使用封裝建立要求的成功或失敗,作為他們定義封裝邊界程度的「測試」。有方法可以這麼做,而無須嘗試版本化封裝成品。
• 理想端狀態應支援的項目。理想的封裝策略可讓控制的穩定 Salesforce 版本快速開發和交付。在整個組織中定義過多封裝可能會為開發小組產生新種類型的複雜性和瓶頸。過度模組化組織也會造成版本變慢且難以執行。從建立並發行數個版本的單一有意義的封裝開始。逐步衍生追蹤封裝。當您的版本步調適合您的業務時,請停止導入封裝。如果業務需要變更或版本品質下降,則反射器封裝會隨著時間變化。理想封裝端狀態為主觀。

無論您決定定義封裝的方式為何,只會透過有效的相依性管理,成功版本寬鬆的封裝。

下方的 模式與反模式清單顯示 Salesforce 封裝的適當 (與不良) 寬鬆配對外觀。您可以使用這些功能在建立之前驗證您的設計,或識別需要重新設計的系統區域。

若要深入瞭解 Salesforce 工具以協助您建立更多可封裝性的資訊,請參閱與可編輯相關的 工具。

在 Salesforce 解決方案的內容中,相依性管理表示識別並建構封裝中中繼資料與安裝封裝之組織中繼資料之間的關係。相依性管理是開發穩定封裝成品的重要部分。

相依性可能會與建立完美分隔且寬鬆連接的功能單位的努力有關。在理想的工程狀態中,寬鬆連接的系統沒有單位之間的相依性。然而,在現實世界中,去除所有相依性並不實際。

通常,使系統可讀取與使用易於業務使用的功能單位之間的平衡需要在系統中單位的完美隔離方面進行權衡。更實際的說法是,Salesforce Platform 標準功能所提供的核心服務會為任何 Salesforce 解決方案建立關鍵的正面相依性。許多內建的延展性、效能和安全性優點都來自於其與平台的整合程度。設計可封裝的 Salesforce 解決方案時,請務必記住,封裝相依性本身並非壞。不良的相依性管理是不良的。

使用 Salesforce 封裝有效管理相依性表示開發和維護小組可以:

• 更快速地上線至新專案,且擁有有限的環境存取權
• 快速開發和測試變更
• 瞭解應如何在較小的特定承諾中提供複雜功能
• 控制版本步調,並減少系統維護/版本中斷期間
• 在任何環境中可預測回復不良變更

使用 Salesforce 管理相依性的技巧相當簡單:

• 使用 傳訊和撤銷來處理元件之間的狀態或未狀態資訊寬鬆轉移。
• 使用自訂中繼資料類型來提供動態執行階段資訊,並支援相依性插入模式。
• 讓 Apex 開發人員使用 抽象或虛擬類別。

最後,您必須決定您組織中允許跨陳述式與程式設計開發的設計模式。最重要的考量事項 (在結構上) 是定義您要新增更多工程複雜度以減少相依性的位置,以及您需要容忍更多相依性以簡化應用程式產生器工作流程的位置。

當您在封裝中建立相依性管理策略時,請考量封裝單位的兩個主要組織原則:水平與垂直。

• 水平界限。在水平範例中,多個封裝可能需要的功能會摘要為水平層。水平層則會成為常見功能的來源,且透過已宣告的相依性存取。將封裝之間的冗餘功能最小化優先於將相依性最小化。
• 垂直邊界。垂直範例可最大化系統部分之間的隔離與寬鬆連接。共用功能受到限制,且類似的工作可能會顯示在單位之間。相依性嚴格限制,以最大化封裝單位之間的隔離。

請注意,這不是其中一項或一項決策。您可以視需要混合垂直與水平範例。通常,開始封裝的最快方法是建立水平服務層。隨著封裝採用的規模和複雜度增加,抽取更多垂直單位有助於簡化複雜的環境設定流程或開發人員上線。

例如,具有兩個功能單位 (A 和 B) 的系統可以使用垂直、水平和垂直水平混合式範例中所排列封裝相依性來結構。

無論您選擇的封裝組織模式為何,都有一些絕對值需要記住:

• 請勿在封裝之間重複中繼資料。多個封裝所需的中繼資料應摘要為宣告為相依性的一或多個封裝。
• 使用 Salesforce Platform 中繼資料 的內建相依性。針對應用程式產生器,Salesforce Platform 提供的內建服務提供大量可快速設定的功能。許多服務都有內建的相依性,難以抽象化為低層級的功能單位。針對指定的中繼資料類型,您需要瞭解其在內建相依性範圍中的所在位置,並使用此瞭解來定義封裝相依性鏈結。請勿透過嘗試強制將寬鬆連接至具有許多內建相依性的標準平台功能來開始封裝採用。當您達到較高層級的功能時,這會增加複雜度 (非值)。這也是落在 標準與自訂 反模式中的另一個方法。從底部 (最少相依性) 封裝中繼資料,並隨著時間迭代。
• 監視您的相依性鏈。避免建立將需要開發人員一次將變更分割成許多不同封裝的封裝相依性鏈。
• 思考來源控制的意義為何。在來源控制中管理封裝的方式有兩種基本方式。第一個為單一單一封裝,其中封裝在資料夾內隔離。__第二個為具有封裝隔離在自己儲存庫中的多個儲存庫。長期管理每種類型的來源策略都有複雜性。在開發人員上線方面,垂直邊界在多個存放庫範例中更有效率。水平邊界在單一空間中更容易理解。同樣地,您可以隨著結構成熟而混合與比對策略。

下方的 模式與反模式清單顯示 Salesforce 封裝的正確 (與不良) 相依性管理外觀。您可以使用這些功能在建立之前驗證您的設計,或識別需要重新設計的系統區域。

若要深入瞭解 Salesforce 用於相依性管理的工具,請參閱與可編譯相關的 工具。

下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。

✨ 在「模式與反模式探索器」中探索更多可封裝的模式。

協助我們讓 Salesforce Well-Architected 與您相關;進行我們的調查以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。