ほとんどの標準タスクおよびユースケースは汎用サービスプロバイダによってカバーされるため、サービス実装コードを追加する必要性が大幅に削減され、縮小されます。
残りのケースでは、ドメイン固有のプログラムチェックなど、ドメインおよびアプリケーションに固有の実際のカスタムロジックに削減されます。
たとえば、AdminService による新しい作成者の作成時に、渡された生年月日が死亡日より前であることを確認する検証をプログラムします。
カスタムサービス実装を追加する最も簡単な方法は、それぞれのサービス定義が含まれている .cds ファイルの横に等号の .js ファイルを配置することです。つまり、ここでは admin-service.js という名前のファイルをプロジェクトの srv フォルダに配置します。このフォルダには、AdminService の定義に使用されるファイル admin-service.cds も含まれているためです (以下の図を参照)。

注記
.js ファイルに必要なカスタムロジックを実装するには、さまざまな方法があります。最も一般的な方法は、cds.ApplicationService のサブクラスを使用して、即座に利用可能な一般的な実装を活用することです。これは、cds.ApplicationService クラスがデフォルトのサービスプロバイダ実装であり、すでに説明した汎用プロバイダをサービス定義に追加するためです。
cds.ApplicationService のサブクラスを登録するには、最初に @sap/cds モジュールをコードの定数 cds に割り当てます (1 行目)。@sap/cds モジュールは、すべての CAP Node.js API へのアクセスを提供する cds ファサードオブジェクトです。
次に、cds.ApplicationService のサブクラスを 4 行目から 6 行目で登録します。このサブクラスでは、後でカスタムロジックを実装します。サブクラスの名称は任意です。ここではサービスインタフェースのように呼ばれています。AdminService。
9 行目では、AdminService クラスを他のモジュールにインポートできるようにします。これは、Node.js でコードを構造化する一般的な手法です。
注記
端末に cds watch を入力してアプリケーションを起動すると、追加されたサービス実装ファイルが以下のような出力を介してログに表示されます。
1[cds] - serving AdminService { path: '/admin', impl: 'srv/admin-service.js' }


