回答:
私が理解しているように、Apiフォルダーで定義されているすべてのインターフェースはサービス契約です。そのため、サービスコントラクトを使用するクラスの実際の実装の代わりに、インターフェースが使用される場所はどこでもです。
例は、このプラグインの実装ですhttps://github.com/magento/magento2/blob/2.3.2/app/code/Magento/GiftMessage/Model/Plugin/OrderGet.php#L78
それは使用しています
protected function getOrderGiftMessage(\Magento\Sales\Api\Data\OrderInterface $order)の代わりに \Magento\Sales\Model\Order
サービス（サービスコントラクトとも呼ばれます）は、Magento 2のコア開発パターンの1つであり、簡単なカスタマイズ/拡張のための安定したインターフェイスを確保します。これらは、コードベースで2つの形式を取ります（どちらも@api、クラスまたはクラスメソッドで注釈を付けて、カスタマイズまたはWeb APIとして公開できる安定したインターフェイスとして識別します）：APIまたはSPI。APIはAPIフォルダーで定義され、完全にリファクタリングされたサービスとAPIのみのモジュールという2つの形式を取ります。
完全にリファクタリングされたサービスは、Customer、Inventory、Tax、およびQuote *モジュールに反映されます（エミュレートするサービスであるCustomer、Quoteにはリファクタリングが必要な領域が残っています）。APIのみのモジュールは、カタログ、販売、およびCMSで見ることができます。完全にリファクタリングされたサービスの場合、サービスメソッドでプラグインを実行するだけで、Web APIとGUIの両方に影響を与えることができます。APIのみのモジュールの場合、サービスメソッドにプラグインしてWeb APIに影響を与える必要がありますが、GUIに影響を与えるには1xスタイルのカスタマイズを行う必要があります。
SPIは、基本的に注釈が付けられたコード内のインターフェースであり、@apiサードパーティがビジネス機能を提供するために実装する予定のスポットです。CarrierInterfaceShippingモジュールに実装するShippingモジュールで定義されたSPI（）の例（Ups）。
サービスフレームワークには、多くの興味深い利点があります。Web API（およびメッセージキュー経由の今後のポスト2.0）vi webapi.xml構成（SOAPおよびRESTスタイルとして）として簡単に公開できます。近い将来（2.0以降）、APIコールアウト（同期コール、または非同期を起動するように構成されている場合はWebhook、メッセージアウト）を追加し、構成を介してすべて管理/公開できます。より安全なインストール/アップグレード-問題の状況をプログラムで特定できます（同じインターフェースを実装する2つ以上の拡張機能）。カスタマイズするメソッド/サービスが1つしかないため、Web APIとGUIの両方に影響を与える合理化されたカスタマイズ（完全にリファクタリングされたモジュールまたはコミュニティによって作成された新しいモジュール/サービス用）。
Magentoサービス契約
基本的に、サービスコントラクトは、データの整合性を保護し、ビジネスロジックを隠すインターフェイスとクラスのセットにすぎません。顧客がこれを使用する理由は、契約により、ユーザーに影響を与えることなくサービスを進化させることができるためです。
このアップグレードが重要な理由は、ユーザーがさまざまなモジュールと対話する方法が変わるためです。Magento 1では、他のモジュールと対話する良い方法はありませんでした。Magento 2のサービス契約を使用すると、システムの構造を心配することなく、データに簡単にアクセスして操作できます。
サービス契約のアーキテクチャ
サービスレイヤーには、データインターフェイスとサービスインターフェイスの2つの異なるインターフェイスタイプがあります。データインターフェイスは、次のパターンを使用してデータの整合性を維持するオブジェクトです。
They’re read-only, since they only define constants and getters.
Getter functions can contain no parameters.
A getter function can only return a simple object type (string, integer, Boolean), a simple type array, and another data interface.
Mixed types can’t be returned by getter functions.
Data entity builders are the only way to populate and modify data interfaces.サービスインターフェイスは、クライアントが使用できるパブリックメソッドのセットを提供します。3つのサービスインターフェイスサブタイプがあります。
Repository Interfaces
Management Interfaces
Metadata Interfacesリポジトリインターフェース
リポジトリインターフェイスは、ユーザーが永続的なデータエンティティにアクセスできるようにします。たとえば、Customer Module内の永続データエンティティは、Consumer、Address、およびGroupです。これにより、3つの異なるインターフェイスが提供されます。
CustomerRepositoryInterface
AddressRepositoryInterface
GroupRepositoryInterfaceこれらのインターフェイスが持つメソッドは次のとおりです。
Save – If there’s no ID, creates a new record, and updates what’s existing if there is one.
Get – Looks for the IDs in the database and returns a certain data entity interface.
GetList – Finds all data entities that correspond with the search criteria, then gives access to the matches by returning the search result interface.
Delete – Deletes the selected entity
DeleteById – Deletes the entity when you only have its key.管理インターフェース
これらのインターフェイスには、リポジトリとは無関係のさまざまな管理機能が含まれています。ここではいくつかの例を示します。
AccountManagementInterface contains functions such as createAccount(), isEmailAvailable(), changePassword(), and activate().
AddressManagementInterface checks whether an address is valid by using the validate() function.パターンの数は絶えず増え続けており、そのように、これらの機能のいくつかはそれらに追加される可能性があります。
メタデータインターフェイス
メタデータインターフェイスは、特定のエンティティに対して定義されているすべての属性に関する情報を提供します。これには、getCustomAttribute（$ name）関数を使用してアクセスできるカスタム属性も含まれます。これらのカスタム属性は次のとおりです。
EAV attributes – Defined via the administration interface for a local site. They can differ according to the site, which means that they can’t be represented in the data entity interface written in PHP.
Extension attributes, for which the extension modules are used.参照：
https://www.interactivated.me/uk/blog/service-contracts-magento-2/