--- schema_version: "1" id: 892a5f397be3c30b605f80c77d8b1e5484efa03e1a724bd3687f521a8b7f1a13 title: アーキテクチャの基本 collection: architect version: next locale: ja-jp portal_url: https://docs.salesforce.com/architect/next/ja-jp/fundamentals/guides/architecture-basics.md canonical_url: https://staging.architect.salesforce.com/docs/architect/ja-jp/fundamentals/guide/architecture-basics.html source_site: staging.architect.salesforce.com content_type: documentation content_hash: c6056868589b7afac14fed69cafb8225de6d229b2cfebdc237c97a8e33ce6e40 products: - 基礎 - Architect Site Content Repo updated_at: 2022-08-01T00:00:00Z --- ## はじめに Salesforce Customer 360 Platform は、すべての個々の Salesforce テナント インスタンス(「組織」とも呼ばれる)に強力な[マルチテナント メタデータ駆動アーキテクチャ](/docs/architect/ja-jp/fundamentals/guide/platform-multitenant-architecture)を提供します。このアーキテクチャの基本ドキュメントでは、Salesforce Platform の基盤となるアーキテクチャで、プラットフォーム上に構築されたソリューションのアーキテクチャに関する主要な考慮事項を作成する領域の概要を説明します。 Salesforce Platform でアーキテクチャを設計するときに理解すべき重要な領域が 3 つあります。 - [トランザクション](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#トランザクション) - [Metadata Versus Data](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#メタデータとデータ) - [プラットフォーム API](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#プラットフォーム-api) ## トランザクション Salesforce Platform では、コード実行やデータベース操作によってトランザクションをインスタンス化できます。Salesforce で設計するための基本的な能力は、プラットフォームでテナントの取引をどのように定義して制御するかを理解することです。すべてのテナントのリソースを維持するために、Salesforce では、トランザクションごと、および組織ごとに計算されるすべてのテナントに制限を設けています。 Salesforce はトランザクション レベルで、コード実行とデータベース トランザクションの個々のインスタンスが共有コンピューティング リソースを独占しないように、[PfR と実行制限](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)を設定します。Salesforce は、組織全体で、[エディションと機能種別](https://help.salesforce.com/s/articleView?id=sf.overview_limits_general.htm&type=5)に基づいて制限を設定します。組織の共有制限には、組織内のすべてのトランザクションの API 使用量のローリング計算も含まれます。これには [API 制限](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm)が適用されます。 Salesforce Platform でのトランザクションの 2 つの主要な部分 (実行コンテキストとデータベース操作) についてもう少し詳しく見てみましょう。 ### Execution Context (実行コンテキスト) Salesforce は、[実行コンテキスト](https://trailhead.salesforce.com/content/learn/modules/apex_basics_dotnet/execution_context)の概念に基づいてトランザクション制限を計算します。Salesforce アプリケーションの場合、これは 1 つの Salesforce 組織内でのカスタムコードの実行に限定されないことを理解しておくことが重要です。実行コンテキストは、プラットフォームランタイムエンジンと、特定のテナントのランタイムエンジンで使用できるすべてのコードに基づいています。つまり、テナントの組織内で定義されたカスタムコード、その組織でインストールされたパッケージのコード、Salesforce Platform サービスに含まれるコードのすべてがトランザクションをインスタンス化できます。プラットフォームは、さまざまな種類の Apex コードを区別し、それらの区別に基づいてガバナ制限を計算します。 [Apex トランザクション制限](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)の詳細については、『 Apex 開発者ガイド 』を参照してください。 ### データベース操作 トランザクションにデータベース操作が含まれる場合、組み込み[の実行順序](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)によって、組織の設定とコードのさまざまな部分の動作が決まります。Salesforce アプリケーションで実行順序を正しく使用する方法を理解する鍵は、この動作によって Salesforce アプリケーションに提供される堅牢なデータの整合性を理解することです。 Salesforce Order of Execution Diagram プラットフォームでは、データベース操作の状態のコンテキスト変数が[トリガーコンテキスト変数](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm)の形式で公開されます。これらのトリガー コンテキスト変数は、Salesforce 組織のすべてのデータベース トランザクションのランタイム状態を説明するものであることを理解しておくことが重要です。この変数は、カスタム Apex トリガーがその組織内で定義されているかどうかに関係なく記述されます。Salesforce フローなどの宣言型ツールで使用できます。 Salesforce では、実行順序で説明されているトリガー動作が正常に完了した*後*、最終的な処理が完了するまで、データはコミットされません (または、データトランザクションは確定されません)。つまり、コンテキストの*前*または*後*のデータトランザクション中に致命的なエラーや不適格な動作が発生すると、プラットフォームによってトランザクション内のすべてのデータ操作がロールバックされます。要求されたレコードデータの変更はデータベースにコミットされず、コミット後ロジックは実行されません。(Apex では、セーブポイントとロールバック動作をより詳細に制御できるように[データベースメソッド](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_transaction_control.htm)が公開されています)。 Salesforce アーキテクチャで避けるべき主要なアンチパターンは、プラットフォームの組み込みの実行順序をショートカットまたは置き換えることです。 これらの組み込みデータ整合性動作のロジックについての詳細は、「[Inside and Out:Salesforce Engineering ブログのトランザクション](https://engineering.salesforce.com/inside-and-out-transactions-b9535faa5924)。 ## メタデータとデータ Salesforce 組織内でカスタマイズおよび拡張する方法を選択する場合、Salesforce Platform の観点から何がデータとみなされ、何がメタデータとみなされるかを理解することが重要です。このデータ/メタデータの区別の背後にある基盤となるアーキテクチャについての詳細は、「[プラットフォーム マルチテナント アーキテクチャ](/docs/architect/ja-jp/fundamentals/guide/platform-multitenant-architecture#プラットフォームデータレイヤー)の基本」ドキュメントを参照してください。 この区別は、アーティファクトを [Sandbox 開発環境](https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm&type=5)にコピーするかどうか、他の環境に移行する方法、[パッケージ](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/sharing_apps.htm)に含めるかどうかなど、アプリケーションの開発ライフサイクルのさまざまな側面に影響します。 次の表に、アプリケーションライフサイクルの主要な部分に関連するデータとメタデータのパフォーマンスの簡単な比較を示します。
動作 データ メタデータ
本番環境から Sandbox 環境にコピー いいえ* あり
メタデータ API による移行 不可 はい**
データ読み込みによる移行 あり 不可
パッケージに含めることができる 不可 はい**
データストレージ制限の対象 あり 不可
*Full Copy Sandbox と Partial Copy Sandbox では、本番からのデータレプリケーションが可能です。
* * 一部のメタデータ型は、メタデータ API やパッケージでは使用できません。例外は、メタデータカバー率レポートで確認できます。
この区別はかなり明白です。たとえば、Salesforce 組織の個々のレコードはデータです。組織のさまざまな [sObject](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_SObjects.htm) はメタデータです。 組織設定機能では、区別がより複雑になる可能性があります。主要な例として、[カスタム設定](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_customsettings.htm)と[カスタムメタデータ型](https://help.salesforce.com/s/articleView?id=sf.custommetadatatypes_about.htm&type=5)があります。どちらの機能でも、実行時に簡単に利用できるように組織内の情報を設定し、データベースレコードと同様の方法で操作および管理することができます。どちらの機能も、コードと自動化で疎結合で柔軟性の高い設計パターンを実現することを目的としています。ただし、カスタム設定はデータとして組織に保存され、カスタムメタデータ型はメタデータとして保存されます。 メタデータであるかどうかは、[メタデータカバー率レポート](https://developer.salesforce.com/docs/metadata-coverage)に表示されるかどうかで判断できます。このレポートでは、特定のメタデータ種別の主要な開発およびリリース動作についても説明します。 ## プラットフォーム API 多くの [Salesforce Platform API](https://help.salesforce.com/s/articleView?id=sf.integrate_what_is_api.htm&type=5) があります。Salesforce Platform API では、さまざまなデータ形式とプロトコル、さまざまな操作種別とタイミングがサポートされます。Salesforce 組織のデータを操作できる API もあれば、特定の組織のメタデータを操作できる API もあります。[大量のトランザクション](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm)を処理するために特別に構築された API もあれば、そうでない API もあります。Salesforce は、リリースのたびに*すべての* Salesforce Platform API のバージョン番号を更新します。 健全なアプリケーションアーキテクチャの重要な部分は、アプリケーション開発者が特定の使用事例に[適切な API](https://help.salesforce.com/s/articleView?id=sf.integrate_what_is_api.htm&type=5) (および API バージョン) を使用することです。Salesforce 組織の組み込み [API 制限](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm)を考慮する必要があります。これらの制限の多くは、エディションと機能の有効化によって決まります。Salesforce Platform API では、[下位互換](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_support_policy.htm)の使用がサポートされます。つまり、新しい API バージョンがリリースされても、特定のバージョンの実装は安定性と一貫性が維持されている必要があります。新しい API バージョンから新規または変更された機能を組み込む場合、新しい API バージョンへの参照をアップグレードする前にアプリケーションのリファクタリングが必要になることがあります。 Salesforce Platform API の種類は多数あり、Salesforce API バージョンのスピードも速いため、Salesforce API を使用するアプリケーションのライフサイクルは非常に複雑になります。アプリケーションの Salesforce Platform API 参照の定期的な評価を計画し、計画された API メンテナンスサイクルに優先順位を付けて、アプリケーションを予測どおりに適切に実行し続ける必要があります。