更新スケジュールについては、こちらを参照してください。

コンポーザブルなソリューションは、迅速かつ高い安定性で調整できます。構成可能なように設計されたシステムは、相互に適切に動作し、サービスの開始と終了を簡単に切り替えることができる有意義なユニット (ビルディングブロック) で構成されています。コンポーザビリティをシステムに組み込むことで、システムの個々のユニットをリファクタリングまたは再構成して、新機能を導入したり、技術的な負債を解消したりできます。コンポーザビリティにより、チームは少量の変更で有意義な機能の構築と提供に集中できるため、より迅速で予測可能な提供サイクルとリリースが可能になります。

コンポーザブルなシステムにより、刺激がビジネスの内部要因によるものか、外部要因によるものかにかかわらず、ビジネスをより迅速かつ安定的に適応させることができます。コンポーザビリティは、システムの耐障害性を高め、ソリューションとアーキテクチャパターンをより意図的にするのに役立ちます。

懸念事項の分離、相互運用性、パッケージ化可能性という 3 つの主要な習慣を構築することで、Salesforce ソリューションをより構成可能にできます。次の図では、これらの習慣の関係を 2 つの方法で確認できます。1 つの構成可能なシステムの 1 つの単位の場合と、構成可能なシステムの複数の単位の場合です。

単一の構成可能なユニット:

構成可能なシステム:

ソフトウェアエンジニアリングおよびシステムアーキテクチャの基本概念であり、懸念の分離では、モジュール単位に分割できる大規模なシステム内でさまざまな懸念事項を特定します。システム内で懸念事項を強固に分離するには、システム全体でアプリケーションロジックと機能の意味のあるユニットを作成する必要があります。単位を小さくすると、アプリケーション配信チームとメンテナンスチームは、大規模なシステムの中断を最小限に抑えながら、変更の方法と場所を理解しやすくなります。また、ユニットを小さくすると、技術的負債に対処するときに作業をどのようにどこに集中させるかが明確になり、システム全体の可読性が向上します。

ビジネス能力を重視して状態を管理することで、Salesforce 組織に懸念をより適切に分離できます。

Salesforce システムの場合、懸念事項を分離するための最良のアプローチでは、ビジネス指向の視点を適用して、システム内のモジュラーユニット (または機能) を特定して整理します。これは、技術的な機能に基づいてユニットを識別するエンジニアリング重視のビューとは異なります。関心事を切り分けるビジネス指向の観点では、ビジネスユーザーとビジネスユーザーに提供するサービスに基づいてシステムのコードとカスタマイズを整理する必要があります。このアプローチは、システム内の冗長または重複する技術的機能の可能性を無視という意味ではありません。つまり、テクニカルサービスは、ビジネスにとって最終的に透明性の高い組織原則に明確に対応付けられています。

ビジネス機能を考慮すると、ビジネス分析チームとディスカバリーチーム間の受け渡しをできるだけ簡単に行うことができます。アプリケーションビルダーが作業単位をコンポーザー可能なアーキテクチャに対応付ける場所を知らない場合、コンポーザー可能なアプリケーション環境ではなく混乱が生じます。また、ビジネスで必要とされる最終状態と組織内のモジュラーユニットの対応付けが明確でない場合、開発チームやベンダーが冗長な機能をシステムに組み込む可能性が高くなります。

ビジネス機能に合わせて機能ユニットを配置するには、次の点を考慮してください。

• Start with jobs to be done (実行するジョブから開始)。ユーザーとビジネス自体のやるべき仕事 (JTBD) に焦点を絞ります。Tony Ulwick が先駆者となり、商品またはサービスを使用して人々が達成しようとしている「仕事」、つまり真の目的を理解することに焦点を絞りました。これは、ユーザーのロール関連の ToDo やビジネスプロセスの個々のステップよりも高い抽象レベルです。たとえば、重複チェックや住所検証などのタスクは、「顧客の 1 つのビューの確立」という高次の機能に分類されます。これらの高次のビジネス機能を明確に把握したら、システムの一部を対応付けることができます。
• **レポート構造ではなく機能指向です。**ビジネスユニットの内部階層は、意味のある機能やジョブを実行するためのプロキシではありません。ビジネスの内部階層は、プロセスとチーム構造に重大な影響を及ぼします (予算は言うまでもありません)。これらは、物流上の重要な考慮事項です。ただし、ビジネスの機能ニーズは、物流よりも抽象化レベルで実行されます。高次の関数ではなくレポート構造を提供するモジュールを作成する場合、そのモジュールがビジネス機能にどのように関連するかを特定するために追加の手順を実行する必要がある場合があります。
• 反復型。まず、ビジネス部門と連携して、最小限の実行可能な商品 (MVP) にどのような機能が有効かを特定します。機能を特定したら、その MVP の作成を開始します。構築するときに、作成する機能単位の中心となるプロセス、メタデータ、およびイベントやメッセージを特定します。外部連動関係のプロセス、メタデータ、イベントまたはメッセージを特定します。より多くの機能ユニットを設計するときに、(サイロ化されたユニットを構築するのではなく) API 管理と連動関係管理を実装して、相互に適切に機能するユニットを構築します。

以下のパターンとアンチパターンのリストは、Salesforce ソリューション内でのビジネス機能に対する適切な (および不適切な) 方向性を示しています。これらを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。

ビジネス機能をより深く理解するために Salesforce から入手できるツールについての詳細は、「Tools Relevant to Composable (コンポーザブルに関連するツール)」を参照してください。

状態管理では、さまざまな時点でのシステム全体の情報の移動に重点が置かれます。効果的な状態管理により、アプリケーションは複雑なデータフローやインタラクションを処理でき、予定外の結果が最小限に抑えられます。モジュール化された Salesforce 組織で状態を管理するには、ユニット内およびユニット間のロジックフローの明確なパスと、予定外の実行動作のグレースフルパスを作成します。状態管理により、モジュール化された Salesforce アプリケーションユニットから一貫したロジックストリームを形成できます。ほとんどの場合、ユニット間の情報フローを構造化するには相互運用性が必要です。

疎結合のユニット間で状態を管理することが困難な場合、Salesforce ではモノリス型のアプリケーション開発になることがよくあります。これは、1 つのフロー内で複雑なプロセスを調整するために構築された大規模な「モノフロー」で確認できます。もう 1 つの例として、大規模な Apex クラスがあります。これは、スパゲッティ・コードや長い一連の 1 回限りの方法を使用して複雑なプロセスを調整します。このようなアプリケーションアーキテクチャでは、リファクタリングとデバッグが難しくなり、新しいチームメンバーやベンダーのオンボーディング時間が長くなります。また、機能は再利用できないため、ビジネスに提供されるアプリケーションの価値も低下します。

モジュラー型の Salesforce 組織全体で状態を管理するには、次の点を考慮してください。

• **ステートフルパターンとステートレスパターンのどちらを使用するかを決定します。**ステートフルパターンでは実行パス全体で情報が保持されますが、ステートレスパターンでは保持されません。疎結合システムでは、ステートレスパターンにより、コンポーネントをより迅速にリファクタリングでき、副作用を減らすことができます。ただし、ステートレスパターンがすべての使用事例に適しているわけではありません。データ操作のコンポーネントを作成する場合、ステートフルパターンはシステム全体のデータの整合性と一貫性を保つのに役立ちます。コンポーネントが次のいずれかの条件を満たしている場合、ステートフルパターンを使用します。
  • より大きな実行パス内の配置を認識することはコンポーネントの動作に不可欠
  • 下流のアクションの結果に基づいてコンポーネントの動作を変更する必要がある (たとえば、下流のコンポーネントからのロールバック/エラー/成功メッセージに基づいて実行を変更する必要がある)
  • コンポーネントは、外部システムまたはダウンストリームシステムからの応答を待って作業を完了する必要があります。
• **ステートフルな情報の有意義なカテゴリを作成します。**状態とはあいまいな用語であり、Salesforce 組織内 (およびそれ以降) のこのような深く幅広い情報に適用でき、単独ではほとんど意味がありません。したがって、ステートフルパターンを作成するために必要な最初のステップは、システム内で最も重要なステートフル実行パス (またはステートフル動作の種類) の有意義なカテゴリを作成することです。考慮すべきカテゴリ:
  • ナビゲーションとフォーム
  • データベース操作
  • 一括処理および一括処理
  • エラー
• ** データベーストランザクションの観点からデータ関連の状態を定義し**ます。プラットフォームの組み込み動作では、Salesforce のデータに関するほとんどの状態の考慮事項が考慮されません。この動作に対して、またはこの動作を回避して管理しようとしないでください。それに合わせて設計します。分散トランザクションロジックを最小化または排除するソリューションを設計します。(詳細については、「データ処理」を参照してください)。
• **機能単位内 (および機能単位全体) で発生する状態を特定します。**機能ユニットをより大きなシステムに組み立てるときは、ステートレスコンポーネントとステートフルコンポーネントの動作を混在させることに留意し、無限ループや処理のギャップが生じる可能性のある組み合わせを回避します。
• ハンドオフを定義します。コンポーネントが状態関連のデータをシステムの別の部分に転送するために使用するメッセージングまたはイベントパターンを検討します。トランザクション認識と処理をコンポーネントに組み込んでいることを確認します。ハンドオフには分散トランザクションロジックを含めないでください。
• プロセス図と状態の対応付けを作成します。プロセス図には、さまざまな時点で情報をシステム内を移動する手順が詳しく説明されています。状態ダイアグラムは、情報 (状態) の実際の変化を示します。Salesforce Diagrams 図形のメタデータフッター部分を使用して、プロセスの各ステップで変化する情報の状態を取得します。プロセス図と状態図を分ける場合は、必ずリンクしてください。この概念は、設計および実装中にプロセスやシステムランドスケープの現在および将来の状態を取得することと混同しないでください。これは、システム内を移動する情報に関するものではないためです。

次のパターンとアンチパターンのリストは、Salesforce ソリューション内の適切な (および不適切な) 状態管理を示しています。これらを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な場所を特定したりできます。

状態を管理するための Salesforce ツールについての詳細は、「Tools Relevant to Composable (コンポーザブルに関連するツール)」を参照してください。

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ パターン & アンチパターンエクスプローラーで、懸念事項を分離するためのより多くのパターンを見つけます。

相互運用性を考慮して設計されたシステムでは、コンポーネントが情報交換を行い、効果的に連携して動作します。モジュラー システムをサイロ化するのではなくコンポーザブルにするには、相互運用性が重要です。疎結合システムでは相互運用性を実現することが困難な場合があります。ユニット間の独立性やシステム全体の全体的な懸念の分離を損なわない一貫した統合方法の標準を確立する必要があります。

相互運用性は、ユーザーエクスペリエンスの品質にも影響します。ユーザーは 1 つの領域 (注文情報など) で作成されたデータを別の領域 (マーケティングキャンペーンなど) で使用できることを期待しています。また、ビルダーは、フローの作成や API への認証など、何らかの方法を習得すれば、次の問題に進むときに使い慣れた手法が機能することを期待しています。相互運用性を考慮した設計を怠ると、アーキテクチャの冗長化、データの複製、プロセスの非効率性、開発およびサポートコストの増加につながります。

メッセージングやイベント、および API 管理を使用して、モジュラー型システムで相互運用性を作成できます。

メッセージとイベントは、システム全体のコンポーネントで情報を送受信できるようにする 2 つの方法です。伝達できるコンテンツという点では、イベントとメッセージは似ています。大きな違いは、送信者の動作です。通常、メッセージを送信するコンポーネントは、データを特定の宛先に送信し、受信者からの何らかの応答を待機します。一方、コンポーネントは、何かが発生するとイベントを出します。特定の宛先はなく、応答も期待できません。これらの動作の違いにより、さまざまなコミュニケーションパターンがサポートされます。メッセージではステートフルな通信パターンがサポートされ、イベントではステートレスな通信パターンがサポートされます。(この区別の詳細については、「状態管理」を参照してください)。

メッセージングとイベントに関するプロトコルと使用事例についてチームを調整することが重要です。基準があいまいな場合、システム全体でパターンが混在するため、次のことが発生する可能性があります。

• 特定の使用事例に誤ったパターンが適用されるパフォーマンスと拡張性の問題
• 処理の一貫性がないため、エンドユーザーにはシステムが不安定に見えます。
• トラブルシューティング時間が長くなり、メンテナンスプロセスが複雑になる

Salesforce 組織内でより疎結合の構造を作成するためにメッセージとイベントを設計するときは、次の点を考慮してください。

• 同期および非同期の使用事例を識別します。イベントにより、システム全体で疎結合のステートレスな非同期通信が可能になります。メッセージングでは、より厳密に制御されたステートフルで同期的なコミュニケーションパターンを使用できます。メッセージまたはイベントを使用するタイミングを決定する場合、コミュニケーションを同期 (およびブロッキングの可能性あり) にするか、非同期とノンブロッキングのどちらにするかを決定する必要があります。
• データ構造を慎重に定義します。コンポーネント間で渡される情報の構造は、疎結合のシステムを管理しやすく一貫性のあるものにするために重要です。(詳細については、「API 管理」を参照してください)。メッセージまたはイベントを設計するときの重要な考慮事項は、情報の構造を変更する必要がある頻度です。メッセージまたはイベント構造が定義されてシステムに実装されると、特にイベントまたはメッセージがすでに外部システムへの情報の送信に使用されている場合、更新の処理が困難になる可能性があります。
• 適切なサイズのメッセージ。一般に、メッセージサイズは小さく抑えることをお勧めします。ただし、メッセージのサイズとメッセージ量の間でバランスを取る作業もあります。少量のデータをより迅速に処理できます。受信者は受信した情報を開梱し、解釈して、その処理方法を決定する必要があるため、処理には追加のオーバーヘッドが発生します。これらのステップの完了にはごくわずかな時間がかかりますが、大規模なシステムに負荷が蓄積され、発生する可能性があります。作業を完了するためにシステム内のコンポーネントで多数の小さなメッセージを連続して処理する必要がある設計は避けます。メッセージのサイズを適切に設定するには、すべてのダウンストリームコンポーネントが多数の後続メッセージを要求または処理できると想定せずに、ダウンストリームコンポーネントが送信された情報を正常に処理および処理するために必要な最小限のデータを考慮してください。
• 拡張性設計。コンポーネントが疎結合になっていると、アーキテクチャの拡張が容易になります。コンポーネント間の連動関係を排除することで、チームは個々のコンポーネントのパフォーマンスや拡張性の向上に取り組むことができますが、他のコンポーネントへの影響を最小限に抑えることができます。ただし、疎結合コンポーネントは、アーキテクチャを大規模に(特に状態の管理に関して)複雑にします。有効なユーザーエクスペリエンスやデータ整合性の理由でロジックや連動関係をより緊密に組み合わせる必要があるプロセスを特定し、それらのプロセスに非同期/イベントベースのパターンを導入しないようにします。代わりに、同期/メッセージベースのパターンと適切なエラー処理を使用してください。

次のパターンとアンチパターンのリストは、Salesforce ソリューション内の適切な (および不適切な) メッセージングとイベントを示しています。これらを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な場所を特定したりできます。

Salesforce メッセージングおよびイベントツールについての詳細は、「Tools Relevant to Composable (コンポーザブルに関連するツール)」を参照してください。特定の使用事例のイベントパターンまたはツールの選択についての詳細は、『Architect’s Guide to Event-Driven Architecture with Salesforce (Salesforce を使用したイベント駆動型アーキテクチャのアーキテクトガイド)』を参照してください。

Salesforce ソリューション内で適切なアプリケーションプログラミングインターフェース (API) 管理を構築すると、システムの個々のコンポーネントが予測可能なコミュニケーションパターンに従うことができます。Salesforce には、Salesforce 外のシステムとの通信に使用する組み込みの安全な API が用意されています。(Salesforce Platform API についての詳細は、「アーキテクチャの基本」を参照してください)。

Salesforce ソリューション内の効果的な API 管理は、真に構成可能なアーキテクチャを構築するための鍵です。これにより、Salesforce 組織内のコンポーネントは効率的に情報を送受信できます。また、ソリューションビルダーは、構築したコンポーネントがシステムの他のコンポーネントと通信する方法に関する明確なプロトコルに従うことができ、不適切な実装を早期に特定できます。さらに、ソリューション作成者は構築またはリファクタリングする特定のコンポーネントに絞り込むことができるため、生産性と品質が向上します。

エンタープライズレベルの API 管理は個別のトピックであり、包括的な API 管理ツールを使用することをお勧めします。このトピックに関する MuleSoft の観点についての詳細は、「API 管理とは」を参照してください。

Salesforce ソリューション内で API 管理機能を構築するには、次の点を考慮してください。

• **API は、コミュニケーションのための予測可能なパターンまたは契約と考えてください。**入力変数または出力変数のデータ型、変数名、特定のパターンに表示する (または表示しない) 情報など、これらは効果的な API 管理のための鍵です。これらの定義は設計標準に表示され、チームはドキュメントを使用してこれらの定義がシステムの特定の部分でどのように実装されているかを見つけることができます。新しい開発からインテグレーション環境への変更をマージすることの難しさを把握する 1 つの方法は、変更を API 通信の実装が不十分な (または API 定義がまったくない) 場所の証拠とみなすことです。

• **API に対する考え方をコードに限定しないでください。**このコンテキストで API を定義するのは、そのメッセージ内のメッセージ構造と変数の一貫性です。この一貫性が維持されている限り、API はコードだけでなく、モジュール化された自動起動 (またはプラットフォームイベントトリガー) フローやフローテンプレートなどの宣言型カスタマイズにも実装できます。API 実装ではなく、パッケージ化可能性とテスト可能性に基づいて、コードで何を定義するか、フローで何を定義するかを決定します。

• ライフサイクルとバージョン管理をシンプルにします。アプリケーション開発のすべての部分と同様に、API にもライフサイクル (定義、構築、テスト、リリース、メンテナンス (廃止を含む)) があります。Salesforce Platform API では、プラットフォームのリリースサイクルが短いため、1 年のうちに複数のバージョンがリリースされます。(この動作についての詳細は、「Salesforce アーキテクチャの基本」を参照してください)。つまり、プラットフォーム API のライフサイクルはかなり複雑です。特定の API の複数のバージョンを Salesforce のユーザーが維持して使用できるようにする必要があるためです。このレベルの複雑さは PaaS の使用事例に適していますが、プラットフォーム上のソリューションアーキテクチャでは不要な複雑さである可能性が高くなります (以下を参照)。アクセシビリティアンチパターン)。API の明確な目的 (エラー処理など) と明確なベースライン定義を定義することに集中します。各 API の 1 つのバージョンのみを使用するようにします。

• API の検出、アクセス、管理を容易にします。API をドキュメント化して、潜在的なコンシューマーが利用可能な API を簡単に見つけられるようにします。API は、機能の一部としてスムーズに機能する必要があります。

• 反復型。一度に 1 つの内部 API の定義と実装のみに集中します。これにより、API 定義を迅速に反復することに集中し、サポート対象の1 つのバージョンに適した形式を見つけて、実装の経験からベスト・プラクティスを確立できます。

次のパターンとアンチパターンのリストは、Salesforce ソリューション内での API 管理の適切さ (および適切でない) を示しています。これらを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。

相互運用性の向上に役立つ Salesforce から入手できるツールについての詳細は、「Tools Relevant to Composable (コンポーザブルに関連するツール)」を参照してください。

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ パターン & アンチパターンエクスプローラーで相互運用性に関するより多くのパターンを見つけます。

Salesforce 組織でパッケージ化可能性を作成するということは、組織の機能は、パッケージとして独立して信頼性高く開発およびリリースできるユニットから取得されるということです。これらの単位は、第 2 世代パッケージ (ISV のロック解除済みパッケージまたは管理パッケージ) の種別として定義するのが理想的です。注意:適切に設計されたソリューションでは、これらのパッケージ種別が排他的に使用されるため、ここでは第一世代管理パッケージについては説明しません。

懸念事項の分離を定義して、Salesforce 組織で機能ユニットを作成することは別問題です。連動関係を明確に把握して管理することで、これらのユニットをパッケージアーティファクトとして正常にバージョン管理することができます。このレベルの安定性とメタデータの分離を実現するには、DevOps (およびアーキテクチャ) の成熟度を大幅に高める必要があります。また、開発時間が短縮され、アプリケーションビルダーの環境が改善され、リリースとリリース管理の予測可能性と制御が可能になります。すべての組織が効果的なパッケージの定義、管理、開発に必要なインフラストラクチャをサポートできるとは限りません。ただし、パッケージ化の達成は、ほぼすべての Salesforce 組織にとって最終的な目標です。

疎結合と連動関係の管理に重点を置くことで、Salesforce ソリューションのパッケージ化可能性を高めることができます。

疎結合系では、個々のピースは強く結び付きません。合成可能なシステムの利点の多くは疎結合にあります。パッケージ化可能なシステムでは、パッケージ間の疎結合 (および組織のインストール) を実現することで、パッケージを明確に定義し、パッケージを使用するチームの開発サイクルの生産性を高めることができます。

Salesforce Platform では、特定の組織に密結合されたパッケージを作成できます。この機能は、パッケージの成熟度が進むにつれて、機能単位を定義したり、組織で適切な懸念事項の分離を試したりするのに役立ちます。ただし、この方法を選択した場合、ソース駆動開発、バージョン管理の使用、アーティファクトの安定性など、真にパッケージ化可能なメタデータの利点はほとんど実現されません。代わりに、次のような密結合システムの欠点が引き続き発生する可能性があります。

• 停止とパフォーマンスの問題を引き起こす単一障害点
• 低速で予測不能なリリース
• 困難で複雑なデバッグおよびトラブルシューティングサイクル
• 拡張性とパフォーマンスの問題

パッケージ化可能な Salesforce システムの最終目標は、疎結合パッケージです。

Salesforce メタデータを効果的なパッケージに分割する場合は、次の点を考慮してください。

• **カスタマイズとは、データとメタデータです。**パッケージ化可能性に関しては、Salesforce Platform ではデータとメタデータの処理が大きく異なります。組織のどの機能がメタデータまたはデータであるかを理解することが重要です。パッケージ化された単位にデータを含めることはできません。パッケージ化されたユニットへの機能の抽象化を開始する場所を決定するときに、チームはデータとして保存されているカスタマイズをパッケージから完全に除外するか、メタデータベースの実装にリファクタリングするかを決定する必要があります。
• パッケージ化がチームに与える影響。Salesforce のパッケージ化の物流上の現実は、パッケージバージョンの作成とリリース作業の多くで、Salesforce CLI や CI/CD テクノロジーのスキルが必要であるということです。つまり、ローコードのカスタマイズもプログラムによるカスタマイズも、パッケージ関連の DevOps テクノロジーを操作できる担当者による時間と注意が必要になります。チームが機能配信を管理する方法によっては、パッケージの採用によって、組織全体のさまざまなチームに大幅な遅延や阻害要因が発生する可能性があります。チームがパッケージによる機能配信を管理できるかどうかを特定し、スキルやスタッフのギャップに対処する計画を立てる必要があります。ソリューションには、ペアプログラミングの採用や、開発環境の CI/CD ジョブの実装などがあります。
• **パッケージ化によって環境戦略がどのように変化するか。**パッケージ主導の開発ライフサイクルでは、初期の作業はゼロ組織で実行する必要があります。これらの一時的なソース駆動開発環境により、サイクルの反復性が高まります。また、開発チームのより詳細な環境アクセス制御と本番組織からの分離もサポートされます。Sandbox または本番環境にのみ存在するパッケージ化されていないメタデータやデータへのパッケージの連動関係が多いほど、チームがスクラッチ組織を実際に使用できる可能性が低くなります。Sandbox でソース追跡を有効にして、スクラッチ以外の組織環境でのソース駆動型開発パターンを許可できますが、開発チームはスクラッチ組織の速度と反復速度の恩恵を受けません。
• パッケージバージョンとリリースの関係。開発パッケージのバージョン管理の頻度とフェーズを計画します。パッケージバージョン要求は 24 時間周期で制限されます (組織ごと)。一般的なベストプラクティスとして、パッケージのバージョン管理は、どのパッケージの内容も変更する必要がないことが確信できる場合にのみ行います。理想的には、品質保証プロセスが完了した後にパッケージバージョンをプロビジョニングします。開発チームがパッケージ作成要求の成功または失敗を、パッケージ境界をどの程度適切に定義しているかの「テスト」として使用できないようにします。これを行うには、パッケージアーティファクトのバージョン管理を試行しない方法があります。
• 理想的な最終状態でサポートされるもの。理想的なパッケージ戦略により、Salesforce リリースを迅速に開発して提供でき、安定的に管理できます。組織全体で定義するパッケージが多すぎると、開発チームが新しい種類の複雑さやボトルネックになる可能性があります。過度にモジュール化された組織では、リリースが遅くなり、困難になる可能性もあります。まず、1 つの意味のあるパッケージのいくつかのバージョンを作成してリリースします。後続のパッケージを段階的に取得します。ビジネスに役立つリリースケイデンスができた時点で、パッケージの導入を停止します。ビジネスニーズの変化やリリース品質の低下に応じて、パッケージを経時的にリファクタリングします。理想的なパッケージの最終状態は主観的です。

パッケージの定義方法に関係なく、疎結合パッケージのバージョン管理は、効果的な連動関係管理によってのみ正常に行われます。

次のパターンとアンチパターンのリストは、Salesforce パッケージでの適切な (および不適切な) 疎結合を示しています。これらを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。

パッケージ性の向上に役立つ Salesforce ツールについての詳細は、「Tools Relevant to Composable (コンポーザブルに関連するツール)」を参照してください。

Salesforce ソリューションのコンテキストでの連動関係管理とは、パッケージのメタデータと、それらのパッケージをインストールする組織のメタデータ間のリレーションを特定して構造化することです。連動関係管理は、安定したパッケージアーティファクトを開発するうえで重要です。

連動関係は、完全に分離され、疎に結合された機能ユニットを作成する努力と対立する可能性があります。理想的なエンジニアリング状態では、疎結合のシステムはユニット間の連動関係がありません。ただし、実際には、すべての連動関係を削除することは現実的ではありません。

多くの場合、システムを読みやすくすることと、ビジネスに適した機能ユニットを使用することのバランスを取るには、システム内のユニットを完全に分離するというトレードオフが必要です。より現実的には、Salesforce Platform の標準機能によって提供されるコア サービスによって、Salesforce ソリューションの主要なネット ポジティブ連動関係が作成されます。拡張性、パフォーマンス、およびセキュリティに関する多くの組み込みの利点は、それらがプラットフォームにどれほど深く統合されているかに起因します。パッケージ化可能な Salesforce ソリューションを設計する場合、パッケージの連動関係は本質的に悪いものではないことに注意してください。不十分な連動関係管理は悪いことです。

Salesforce パッケージを使用した効果的な連動関係管理により、開発チームとメンテナンスチームは次のことができます。

• 新しいプロジェクトへの迅速なオンボーディングと制限された環境アクセス
• 変更をすばやく開発してテストする
• 複雑な機能を小さく具体的なコミットメントでどのように提供すべきかを理解する
• リリース頻度を制御し、システムメンテナンス/リリース停止期間を短縮
• あらゆる環境での悪影響を予測的にロールバック

Salesforce を使用した連動関係管理の手法は非常に簡単です。

• メッセージングとイベントを使用して、コンポーネント間のステートフルまたはステートレス情報の適切な引き継ぎを処理します。
• カスタムメタデータ型を使用して、動的な実行時情報を提供し、連動関係インジェクションパターンをサポートします。
• Apex 開発者に抽象クラスまたは仮想クラスを使用させる。

最終的には、宣言型開発とプログラム開発の両方で組織で使用できるデザインパターンを決定する必要があります。(アーキテクチャ上の) 最も重要な考慮事項は、連動関係を減らすためにエンジニアリングの複雑さを増す箇所と、アプリケーションビルダーのワークフローを簡略化するためにより多くの連動関係を許容する必要がある箇所を定義することです。

連動関係管理戦略をパッケージに組み込む場合は、パッケージ単位に関する 2 つの主要な整理原則 (水平と垂直) を考慮してください。

• 水平境界。水平パラダイムでは、複数のパッケージで必要とされる可能性のある機能が水平レイヤーに抽象化されます。水平レイヤーは共通の機能のソースになり、宣言された連動関係を介してアクセスします。パッケージ間で重複する機能を最小限に抑えることは、連動関係を最小限に抑えることよりも優先されます。
• 縦方向の境界。垂直パラダイムでは、システムの部分間の分離と疎結合が最大化されます。共有機能は制限され、ユニット間で同様の作業が表示されることがあります。パッケージ単位間の分離を最大化するために、連動関係は厳密に制限されます。

これは決定事項ではないことに注意してください。必要に応じて、縦方向と横方向のパラダイムを組み合わせることができます。多くの場合、パッケージから開始する最も早い方法は、水平サービスレイヤーを作成することです。パッケージの採用の規模と複雑さが大きくなるにつれて、縦方向の単位を抽象化することで、複雑な環境設定プロセスや開発者のオンボーディングを簡略化できます。

たとえば、2 つの機能単位 (A と B) があるシステムは、縦方向、横方向、および縦-横方向のハイブリッドパラダイムで配置されたパッケージ連動関係で構造化できます。

選択するパッケージ整理パラダイムに関係なく、次の点に留意してください。

• **パッケージ間でメタデータを複製しないでください。**複数のパッケージで必要なメタデータは、連動関係として宣言された 1 つ以上のパッケージに抽象化する必要があります。
• **Salesforce Platform メタデータの組み込み連動関係を活用します。**アプリケーションビルダーの場合、Salesforce Platform が提供する組み込みサービスでは、すばやく設定できる多くの機能が提供されます。これらのサービスの多くには組み込み連動関係があり、下位レベルの機能単位に抽象化することは困難です。特定のメタデータ型の場合、それが組み込み連動関係のどこに当てはまるかを理解し、その理解に基づいてパッケージ連動関係チェーンを定義する必要があります。多くの組み込み連動関係を持つ標準プラットフォーム機能に無理に疎結合を組み込むことで、パッケージの採用を開始しないでください。高次の機能に到達するにつれて (値ではなく) 複雑さが増します。また、標準対カスタムのアンチパターンに分類される別の方法もあります。メタデータを下から (連動関係が最も少ない) 上にパッケージ化し、経時的に反復します。
• 連動関係チェーンに注意してください。開発者が一度に多くの異なるパッケージに変更を分割する必要があるパッケージ連動関係チェーンの作成は避けてください。
• ソース制御に何が適しているかを考えます。ソース制御でパッケージを管理する基本的な方法は 2 つあります。1 つ目は、パッケージがフォルダ内で分離されている 1 つの独占リポジトリです。2 つ目は、パッケージが独自のリポジトリに隔離されている複数のリポジトリです。各種ソース戦略の長期的な管理には複雑さがあります。開発者のオンボーディングの観点では、複数のリポジトリパラダイムで縦方向の境界がより効率的です。横方向の境界は、独占情報でよりわかりやすくなります。ここでも、アーキテクチャの成熟に合わせて戦略を組み合わせることができます。

次のパターンとアンチパターンのリストは、Salesforce パッケージでの適切な (および不適切な) 連動関係管理を示しています。これらを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。

連動関係管理用の Salesforce ツールについての詳細は、「Tools Relevant to Composable」を参照してください。

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ パターン & アンチパターンエクスプローラーでパッケージ化可能なパターンをさらに見つけます。

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくためのアンケートにご協力ください。また、今後の展望についてもお聞かせください。