---
schema_version: "1"
id: 500916f9093b57a668028f035d19951b83f78e5785a56e9252f9a425bbe07b06
title: コンポーザブル
collection: architect
version: next
locale: ja-jp
portal_url: https://docs.salesforce.com/architect/next/ja-jp/well-architected/guides/composable.md
canonical_url: https://staging.architect.salesforce.com/docs/architect/ja-jp/well-architected/guide/composable.html
source_site: staging.architect.salesforce.com
content_type: documentation
content_hash: 542aae1df2e474c373e98fafc0c6848fcfa74a875e5466c552d03746682e548e
products:
  - 適切に設計された
  - Architect Site Content Repo
updated_at: 2024-07-01T00:00:00Z
---
> 更新スケジュールについては、[こちら](/docs/architect/ja-jp/well-architected/guide/contributors)を参照してください。

## はじめに

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

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

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

<b>単一の構成可能なユニット:</b>

<a href="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-capabilities.jpeg" target="_blank">
    <img style="border:1px solid #e5e5e5;margin:2rem 0rem;width:50%;" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-capabilities.jpeg" alt="次の図は、ネストされた 3 つのカードで構成可能なトピックがどのように関連するかを示しています。 一番内側のカードは機能単位、次のレイヤーは相互運用性、外側のレイヤーは梱包可能性です。">
</a>

<b>構成可能なシステム:</b>

<a href="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-multi-package-capabilities.jpeg" target="_blank">
    <img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-multi-package-capabilities.jpeg" alt="次の図は、ネストされた 3 つのカードで構成可能なトピックがどのように関連するかを示しています。 一番内側のカードは機能単位、次のレイヤーは相互運用性、外側のレイヤーは梱包可能性です。">
</a>

## 懸念事項の分離

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

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

### 機能単位

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

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

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

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

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

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

### 状態管理

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

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

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

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

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

状態を管理するための Salesforce ツールについての詳細は、「[Tools Relevant to Composable](/docs/architect/ja-jp/well-architected/guide/composable#コンポーザブルに関連するツール) (コンポーザブルに関連するツール)」を参照してください。

### 懸念パターンとアンチパターンの分離

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

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/adaptable-separation-of-concerns)で、懸念事項を分離するためのより多くのパターンを見つけます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="3"><b>機能単位</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 命名規則では、機能単位を示す方法について説明しています。
                <br> 現在定義されているすべての機能単位 (および関連する命名規則) のリストが存在する
                <br> ・機能単位の追加や変更の提案基準が存在する</td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 設計標準が存在しないか、機能単位と使用事例を扱っていない
            </td>
        </tr>
        <tr>
            <td><b>ドキュメント:</b>
                <br> - 組織の機能単位を明確に示すシステムランドスケープダイアグラム
                <br> - すべてのドキュメントと実装図にコンポーネントの機能単位が明確に示されている
                <br> - 個々のコンポーネントのドキュメントには、コンポーネントの機能単位の対応付けが含まれます。
                <br> -機能単位内のすべてのコンポーネントが検索可能で、見つけやすい
            </td>
            <td><b>ドキュメント:</b>
                <br> - コンポーネントのドキュメントが存在しない
                <br> - コンポーネントドキュメントにはコンポーネントが属する機能単位が記述されていますが、その機能単位の定義が表示されるのはコンポーネントドキュメントのみです。
                <br> -特定の機能単位を検索できない、または検索が機能単位内のすべてのコンポーネントの識別に役立たない
            </td>
        </tr>
        <tr>
            <td><b>組織内：</b>
                <br> -特定のメタデータ(フロー、Apexクラス、Lightningページなど)の機能単位の配置をすばやく特定できます。
                <br> - 機能単位にはビジネスにわかりやすい表示ラベルを付ける
            </td>
            <td><b>組織内：</b>
                <br> -メタデータの機能単位の配置を特定できない
                <br> - 機能単位情報に一貫性がないか、不正確である
                <br> - 機能単位情報の表示ラベルが、ビジネスユーザーにとって無意味なエンジニアリング関連の用語で付けられている
            </td>
        </tr>
         <tr>
            <td rowspan="4"><b>状態管理</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> -ステートフル設計とステートレス設計の使用事例が明確である
                <br> - ステートレス通信の承認済みパターンが存在する
                <br> - ステートフルなコミュニケーションの承認済みパターンが存在する
                <br> - 状態のカテゴリをクリア
            </td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 設計標準が存在しないか、状態/ステートレスパターンと使用事例を扱っていない
            </td>
        </tr>
        <tr>
            <td><b>ドキュメント:</b>
                <br> - ステートフルまたはステートレス通信を処理するすべてのコンポーネントは、実装されたパターンを示します。
                <br> -特定のステートフル/ステートレスパターンを実装しているすべてのコンポーネントを検索して見つけることができます。
                <br> - プロセス図とインタラクション図には、状態カテゴリと引き継ぎに関する詳細が表示されます。
            </td>
            <td><b>ドキュメント:</b>
                <br> - コンポーネントのドキュメントが存在しない
                <br> - コンポーネントのドキュメントには実装されたステートフル/ステートレスパターンが説明されていますが、定義が表示されるのはここのみです。
                <br> -特定のパターンを検索できない、または検索がそのパターンを使用するすべてのコンポーネントの識別に役立つとは限らない
            </td>
        </tr>
        <tr>
            <td><b>Apex:</b><br> - すべてのデータ操作でセーブポイントとロールバック動作が使用される</td>
            <td><b>Apex:</b><br> - セーブポイントとロールバック動作が使用されない</td>
        </tr>
        <tr>
            <td><b>フロー内:</b><br> - 障害パスがあり、レコードのロールバック要素が使用されている</td>
            <td><b>フロー内:</b><br> - [レコードをロールバック] 要素が使用されていない</td>
        </tr>
    </tbody>
</table>

## 相互運用性

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

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

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

### メッセージングとイベント

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

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

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

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

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

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

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

### API 管理

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

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

エンタープライズレベルの API 管理は個別のトピックであり、包括的な API 管理ツールを使用することをお勧めします。このトピックに関する MuleSoft の観点についての詳細は、「[API 管理と](https://www.mulesoft.com/resources/api/what-is-api-management#:~:text=API%20management%20is%20the%20process,create%20are%20consumable%20and%20secure.)は」を参照してください。

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

- **API は、コミュニケーションのための*予測*可能なパターンまたは契約と考えてください。**入力変数または出力変数のデータ型、変数名、特定のパターンに表示する (または表示しない) 情報など、これらは効果的な API 管理のための鍵です。これらの定義は設計標準に表示され、チームはドキュメントを使用してこれらの定義がシステムの特定の部分でどのように実装されているかを見つけることができます。新しい開発からインテグレーション環境への変更をマージすることの難しさを把握する 1 つの方法は、変更を API 通信の実装が不十分な (または API 定義がまったくない) 場所の証拠とみなすことです。
- **API に対する考え方をコードに限定しないでください。**このコンテキストで API を定義するのは、そのメッセージ内のメッセージ構造と変数の一貫性です。この一貫性が維持されている限り、API はコードだけでなく、モジュール化された自動起動 (またはプラットフォームイベントトリガー) フローやフローテンプレートなどの宣言型カスタマイズにも実装できます。API 実装ではなく、[パッケージ化](/docs/architect/ja-jp/well-architected/guide/composable#パッケージ性)可能性と[テスト可能性](/docs/architect/ja-jp/well-architected/guide/resilient#アプリケーションライフサイクル管理)に基づいて、コードで何を定義するか、フローで何を定義するかを決定します。

- ライフサイクルとバージョン管理を**シンプルにし**ます。アプリケーション開発のすべての部分と同様に、API にもライフサイクル (定義、構築、テスト、リリース、メンテナンス (廃止を含む)) があります。Salesforce Platform API では、プラットフォームのリリースサイクルが短いため、1 年のうちに複数のバージョンがリリースされます。(この動作についての詳細は、「Salesforce [アーキテクチャの基本](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#プラットフォーム-api)」を参照してください)。つまり、プラットフォーム API のライフサイクルはかなり複雑です。特定の API の複数のバージョンを Salesforce のユーザーが維持して使用できるようにする必要があるためです。このレベルの複雑さは PaaS の使用事例に適していますが、プラットフォーム上のソリューションアーキテクチャでは不要な複雑さである可能性が高くなります (以下を参照)。[アクセシビリティアンチパターン](/docs/architect/ja-jp/well-architected/guide/intentional#読みやすさパターンとアンチパターン))。API の明確な目的 (エラー処理など) と明確なベースライン定義を定義することに集中します。各 API の 1 つのバージョンのみを使用するようにします。
- **API の検出、アクセス、管理を容易にします。**[API をドキュメント](/docs/architect/ja-jp/well-architected/guide/intentional#設計標準)化して、潜在的なコンシューマーが利用可能な API を簡単に見つけられるようにします。API は[、機能](/docs/architect/ja-jp/well-architected/guide/composable#機能単位)の一部としてスムーズに機能する必要があります。
- **反復型**。一度に 1 つの内部 API の定義と実装のみに集中します。これにより、API 定義を迅速に反復することに集中し、サポート対象の*1 つ*のバージョンに適した形式を見つけて、実装の経験からベスト・プラクティスを確立できます。

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

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

### 相互運用性パターンとアンチパターン

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

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/adaptable-interoperability)で相互運用性に関するより多くのパターンを見つけます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="3"><b>メッセージングとイベント</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 同期パターン (メッセージング) と非同期パターン (イベント) を使用する状況に関する明確な標準が存在する
                <br> - イベントおよびメッセージ構造には明確な標準がある
            </td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 設計標準が存在しないか、同期パターンと非同期パターンの明確な標準やメッセージまたはイベント構造の明確な標準がない
            </td>
        </tr>
        <tr>
            <td><b>組織内：</b>
                <br> - 内部システムメッセージングに使用されるプラットフォームイベントの表示ラベルが明確である
                <br> - Salesforce フローツールでシステム全体のメッセージングまたはイベントサービスを参照する
                <br> -一貫したメッセージングとイベントパターンがフローとコードに表示される
            </td>
            <td><b>組織内：</b>
                <br> - 内部システムメッセージングに使用されるプラットフォームイベントの表示ラベルが明確でない、または存在しない
                <br> - メッセージングパターンとイベントパターンのさまざまな戦略がフローとコードで表示される
            </td>
        </tr>
        <tr>
            <td><b>Apex または LWC の場合:</b>
                <br> - カスタムイベント定義の範囲が制限される (システム全体のイベントやメッセージがコードで定義されない)
                <br> - Apex のシステム全体のメッセージングサービスまたはイベントサービスは、Salesforce フローツールで使用できるようにアノテーションが付けられます。
            </td>
            <td><b>Apex または LWC の場合:</b>
                <br> -システム全体のメッセージおよび/またはイベント構造がApexまたはJavaScriptで定義されている
                <br> - Apex で定義されたシステム全体のイベント構造またはメッセージ構造をフローなどのツールで使用できない
            </td>
        </tr>
         <tr>
            <td rowspan="3"><b>API 管理</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - クロスコンポーネント通信用の明確なプロトコル (API) が存在する
                <br> - プロトコル/API は、ビルダーが検索および検索できる論理グループにまとめられています。
                <br> -プロトコル/API により、変数のデータ型、変数名、必須または省略可能を定義し、使用する状況を明確に説明
            </td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 設計標準が存在しないか、API と使用事例を定義していない
            </td>
        </tr>
        <tr>
            <td><b>ドキュメント:</b>
                <br> - すべてのコンポーネントのドキュメントに、実装済みの API/通信プロトコルが明記されている
                <br> -特定の API またはプロトコルを検索し、それが実装されているコンポーネントを識別できる
            </td>
            <td><b>ドキュメント:</b>
                <br> - コンポーネントのドキュメントが存在しない
                <br> - コンポーネントドキュメントにはコンポーネント内に実装された API が記載されていますが、API 定義が表示されるのはここのみです。
                <br> -特定の API またはプロトコルを検索できない、または API またはプロトコルが実装されたコンポーネントを特定できない
            </td>
        </tr>
        <tr>
            <td><b>組織内：</b>
                <br> - 内部コミュニケーション用の API メッセージ形式と変数がカスタムメタデータ型で定義されている
                <br> - 内部コミュニケーション用の API メッセージ形式と変数がプラットフォームイベントで定義されている
                <br> - コードおよび宣言型カスタマイズでは、情報を送受信するために適切なカスタムメタデータ型 (またはプラットフォームイベント) を参照します。
            </td>
            <td><b>組織内：</b>
                <br> - システムのコンポーネント間 (コードおよび宣言型カスタマイズ) の通信がアドホックである
                <br> - API は、Salesforce と外部システム間の通信専用に定義されています。
            </td>
        </tr>
    </tbody>
</table>

## パッケージ性

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

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

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

### 疎結合

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

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

- 停止とパフォーマンスの問題を引き起こす単一障害点
- 低速で予測不能なリリース
- 困難で複雑なデバッグおよびトラブルシューティングサイクル
- [拡張性](/docs/architect/ja-jp/well-architected/guide/reliable#拡張性)と[パフォーマンス](/docs/architect/ja-jp/well-architected/guide/reliable#performance)の問題

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

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

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

パッケージの定義方法に関係なく、疎結合パッケージのバージョン管理は、効果的な[連動関係管理](/docs/architect/ja-jp/well-architected/guide/composable#連動関係管理)によってのみ正常に行われます。

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

パッケージ性の向上に役立つ Salesforce ツールについての詳細は、「[Tools Relevant to Composable](/docs/architect/ja-jp/well-architected/guide/composable#コンポーザブルに関連するツール) (コンポーザブルに関連するツール)」を参照してください。

### 連動関係管理

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

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

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

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

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

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

- [メッセージングとイベント](/docs/architect/ja-jp/well-architected/guide/composable#メッセージングとイベント)を使用して、コンポーネント間のステートフルまたはステートレス情報の適切な引き継ぎを処理します。
- カスタムメタデータ型を使用して、動的な実行時情報を提供し、連動関係インジェクションパターンをサポートします。
- Apex 開発者に抽象クラスまたは[仮想クラス](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_extending.htm)を使用させる。

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

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

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

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

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

<a href="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-vertical-horizontal-slices.jpeg" target="_blank">
    <img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-vertical-horizontal-slices.jpeg" alt="次の図は、A と B の 2 つのパッケージを示しています。これらは、共有連動関係を持たないように構築され (縦のスライス)、多くの共通サービスを持ち (横のスライス)、それぞれが混在するように構築されています (ハイブリッド)。">
</a>

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

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

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

連動関係管理用の Salesforce ツールについての詳細は、「[Tools Relevant to Composable](/docs/architect/ja-jp/well-architected/guide/composable#コンポーザブルに関連するツール)」を参照してください。

### パッケージ化可能性パターンとアンチパターン

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

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/adaptable-packageability)でパッケージ化可能なパターンをさらに見つけます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="5"><b>疎結合</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 命名規則では、パッケージ単位の表記方法を指定します。
                <br> 現在定義されているすべてのパッケージ単位 (および関連する命名規則) のリストを検索して見つけることができます。
                <br> ・パッケージ単位の追加や変更の提案基準が存在する
                <br> - (省略可能) カスタム設定の承認済み使用事例がすべて明確にリストされている (ある場合)
            </td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 設計標準が存在しないか、パッケージ単位と使用事例を扱っていない
            </td>
        </tr>
        <tr>
            <td><b>組織内：</b>
                <br> - カスタムメタデータ型により、コードおよび宣言型カスタマイズの動的な実行時情報が提供されます。
                <br> - カスタム設定が存在しないか、カスタム設定がほとんど存在せず、パッケージ化された機能に関連するものがない
                <br> - コードまたは宣言型カスタマイズの動的かつ実行時情報を提供するカスタムオブジェクトが存在しない
            </td>
            <td><b>組織内：</b>
                <br> - カスタム設定が使用される
                <br> - カスタムオブジェクトは、コードまたは宣言型カスタマイズの動的な実行時情報を提供する目的で存在します。
                <br> - カスタムメタデータ型は、コードおよび宣言型カスタマイズの動的かつ実行時情報を提供するのに使用されない (または一貫して使用されない)
            </td>
        </tr>
        <tr>
            <td><b>Apex:</b>
                <br> Common Services およびボイラープレートコードは、抽象または仮想 Apex クラスを使用して定義されます。
                <br> - 動的で実行時の情報に依存するメソッドは、適切なカスタムメタデータ型を参照します。
            </td>
            <td><b>Apex:</b>
                <br> - Common Services とボイラープレートコードが他のクラスと容易に区別されない
                <br> - クラスやメソッド間の内部参照が追跡しづらく、コードベース全体で一貫性がない
                <br> - メソッドが動的で実行時の情報にアクセスするために一貫した方法を使用していないか、メソッドがカスタムオブジェクトで実行時の動作情報を照会しているか、コードがカスタム設定を参照している
            </td>
        </tr>
        <tr>
            <td><b>ソース制御および開発環境の場合:</b>
                <br> - package.xml ファイルは、初期段階または概念実証プロジェクトマニフェストにのみ表示されます。
            </td>
            <td><b>ソース制御および開発環境の場合:</b>
                <br> - package.xml ファイルはメタデータリリースの制御に使用されます。
            </td>
        </tr>
        <tr>
            <td><b>パッケージ内：</b>
                <br> -組織依存のロック解除済みパッケージは、初期段階または概念実証実験でのみ使用されます。
                <br> - 本番または Sandbox で未管理パッケージが定義されていない
            </td>
            <td><b>パッケージ内：</b>
                <br> - すべてのパッケージが組織依存のロック解除済みパッケージである
                <br> - 未管理パッケージが本番または Sandbox で定義されている
            </td>
        </tr>
         <tr>
            <td rowspan="4"><b>連動関係管理</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 連動関係を宣言するための基準が存在する
                <br> - 連動関係の導入または変更に関する基準が存在する
            </td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 設計標準が存在しないか、連動関係の宣言方法を扱っていない
            </td>
        </tr>
        <tr>
            <td><b>ソース制御：</b>
                <br> - ロック解除済みパッケージのパッケージバージョンでは、別名 (<code>最新</code>) を使用して <code>sfdx-project.json</code> マニフェストで連動関係を宣言します。
                <br> -開発者はスクラッチ組織を作成し、ソース制御からパッケージメタデータを正常にリリースできます。
            </td>
            <td><b>ソース制御：</b>
                <br> - ロック解除済みパッケージのパッケージバージョンが <code>sfdx-project.json</code> マニフェストで明示的に宣言されている (<code>最新の</code>別名がない)
                <br> - 開発者がソース制御を使用してスクラッチ組織で正常に作業できない
            </td>
        </tr>
        <tr>
            <td><b>パッケージ内：</b>
                <br> -パッケージ間でメタデータが重複しない
                <br> -パッケージ開発の場合、初期段階の開発作業はすべてスクラッチ組織で行われます。
            </td>
            <td><b>パッケージ内：</b>
                <br> -異なるパッケージのメタデータを複製することで連動関係を回避
                <br> - 早期パッケージ開発は Developer Sandbox で行われるか、早期パッケージ開発はスクラッチ組織では実行できません。
            </td>
        </tr>
        <tr>
            <td colspan="2">関連トピック:<a href="/docs/architect/ja-jp/well-architected/guide/composable#疎結合">疎結合</a></td>
        </tr>
    </tbody>
</table>

## コンポーザブルに関連するツール

<table class="tools-table"><tbody><tr><th>ツール</th><th>説明</th><th>懸念事項の分離</th><th>相互運用性</th><th>パッケージ性</th></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_rest.htm">Apex REST Webサービス</a></td><td>ApexクラスおよびメソッドをREST経由で外部アプリケーションに公開</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_web_services.htm#apex_web_services">Apex SOAP Web サービス</a></td><td>Apex クラスおよびメソッドを SOAP 経由で外部アプリケーションに公開する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">変更データキャプチャ</a></td><td>Salesforce レコードへの変更を公開</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.custommetadatatypes_overview.htm&language=en_US&r=https%3A%2F%2Fwww.google.com%2F&type=5">カスタムメタデータ型</a></td><td>再利用可能なカスタマイズ可能なパッケージ化可能な機能を定義する</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_decorators">デコレーター</a></td><td>API として関数またはプロパティを公開</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_devhub.htm">Dev Hub</a></td><td>スクラッチ組織、第二世代パッケージ、Einstein機能を管理します。</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/generic_streaming_intro.htm">一般的なイベント (従来)*</a></td><td>Salesforce データの変更に関連付けられていないカスタムイベントの送信</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.data_ui_api">Lightning Data Service</a></td><td>コンポーネント間でのデータのキャッシュと共有</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_intro.htm">メタデータ API</a></td><td>Salesforce 環境間のカスタマイズのリリース</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_supported_mdapi_types.htm">メタデータカバー率レポート</a></td><td>複数のチャネルでサポートされるメタデータの対象範囲を決定する </td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://docs.mulesoft.com/composer/ms_composer_overview">MuleSoft Composer</a></td><td>コードではなくクリックを使用してデータのプロセスの自動化を構築</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">送信メッセージ</a></td><td>項目値の更新時に外部エンドポイントにメッセージを送信</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">プラットフォームイベント </a></td><td>ほぼリアルタイムのイベントデータを含む安全でスケーラブルなメッセージを送信する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/blogs/2021/07/pub-sub-api-building-event-driven-integrations-just-got-even-easier">Pub/Sub API</a></td><td>プラットフォームイベント、変更データキャプチャ、またはリアルタイムイベント監視への登録</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/pushtopic_events_intro.htm">PushTopic イベント (従来)*</a></td><td>ユーザー定義の SOQL クエリに一致する変更通知の送受信</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/tools/sfdxcli">Salesforce CLI</a></td><td>Salesforce 組織で作業するときの自動化の開発と構築</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/ja-jp/reference-diagrams/guide/introduction">Salesforce の図</a></td><td>ビジネス能力と技術的な詳細を示す図を作成する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-expanded">Visual Studio Code 向け Salesforce 拡張機能 (拡張)</a></td><td>Salesforce 開発の公式 VS Code 拡張機能</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs.htm">スクラッチ組織</a></td><td>Salesforce コードとメタデータを破棄可能な組織にリリースする</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp.htm">第二世代管理パッケージ</a></td><td>AppExchange 向けアプリケーションの開発と配布</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_tooling.meta/api_tooling/intro_tasks.htm">Tooling API</a></td><td>Lightning プラットフォームアプリケーション用のカスタム開発ツールまたはアプリケーションの作成</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm">ロック解除済みパッケージ</a></td><td>メタデータの整理、アプリケーションのパッケージ化、AppExchange アプリケーションの拡張</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr>
<td colspan="5">*Salesforce は、現在の機能の範囲内で引き続き PushTopic および Generic Events をサポートしますが、この技術にさらに投資する予定はありません。</td>
</tr>
</table>

## コンポーザブルに関連するリソース

<table class="tools-table"><tbody><tr><th>リソース</th><th>説明</th><th>懸念事項の分離</th><th>相互運用性</th><th>パッケージ性</th></tr>
<tr><td><a href="https://blogs.mulesoft.com/api-integration/strategy/a-primitive-look-at-digital-integration/">デジタルインテグレーションのプリミティブな考察</a></td><td>接続の概念の共通言語を開発する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://medium.com/p/cd4b7ebe926b">Salesforce を使用したドメイン駆動設計の適用</a></td><td>ビジネス機能に関するソリューション指向</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.218.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_plan_best_practices.htm">第二世代パッケージのベストプラクティス</a></td><td>2GP パッケージ化のパターンと方法を理解する</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.238.0.sfdx_dev.meta/sfdx_dev/packaging_packageable_components.htm">管理パッケージで使用可能なコンポーネント</a></td><td>管理パッケージメタデータコンポーネントを理解する</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/ja-jp/resources/guide/design-standards-template">設計標準テンプレート</a></td><td>組織の設計標準を作成する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/ja-jp/decision-guides/guide/event-driven">イベント駆動型アーキテクチャ決定ガイド</a></td><td>イベント駆動型アーキテクチャのパターンとツールの比較</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/events_anti_patterns.htm">イベントのアンチパターン</a></td><td>イベントを使用するときに避けるべきアンチパターンの特定</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://blogs.mulesoft.com/dev-guides/design-message-driven-and-event-driven-apis/">メッセージ駆動型およびイベント駆動型の API の設計方法</a></td><td>MuleSoft 開発者ガイドで違いを確認する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/en/content/learn/modules/jobs-to-be-done-framework-for-designers/learn-about-the-jobs-to-be-done-framework">完了すべきジョブフレームワークについて</a></td><td>Trailhead での JTBD の探索</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/managing-global-state.html">B2C Commerce でのグローバル状態の管理</a></td><td>コンポーネント間でデータを簡単に渡して状態を維持</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/messaging/overview/">メッセージングガイドライン</a></td><td>関連情報を伝え、喜びの瞬間を作り出す</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/messaging/types/">メッセージング種別</a></td><td>ユーザー操作の性質によるさまざまなメッセージング種別の理解</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.238.0.api_meta.meta/api_meta/meta_types_list.htm">メタデータ型</a></td><td>Salesforce 組織のさまざまなメタデータの種別を理解する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.salesforce_app_enable_push_notifications.htm&type=5">モバイルアプリケーション通知種別</a></td><td>Salesforce モバイルアプリケーションの通知種別について</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_visualforce_best_practices.meta/salesforce_visualforce_best_practices/pages_best_practices_perf_code_view_state.htm">ビューステートの最適化</a></td><td>Visualforce ページでの状態の維持</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm">Salesforce 開発者エクスペリエンス (DX)</a></td><td>Lightning プラットフォームでのアプリケーションの管理および開発</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_unsupported_types.htm">サポートされないメタデータ型</a></td><td>メタデータ API で使用できないコンポーネントを特定する</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
</table>

## ご意見をお聞かせください

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