Service Layer(Domain Logic Patterns)

概要

• アプリケーション境界を定め、プレゼンテーションや外部システムに対して操作のセットを提供する。このレイヤ自身は、リモートアクセス・レスポンスのとりまとめ・トランザクション境界の管理などを行う。
• 公開すべきサービス・操作は、ユースケースから識別するといいらしい。
  

バリエーション
ビジネスロジックの一種としての側面
問題領域に特化した「ドメインロジック」とは別に、システム的なロジック（アプリケーションロジック）を記述する場所としてService Layerを利用することができる。ワークフローなどがあげられている。

実装のバリエーション
Domain FacadeとOperation Scriptというアプローチが書かれている。
Domain Facadeはその名のとおり、Domain ModelのFacadeとして機能し、基本的にロジックは記述しない。クライアント層への操作セットを提供するのが主な役割。
Operation Scriptは、これまたその名のとおり、アプリケーションロジックを実装する（ドメインロジックはDomain Modelに委譲する）。Service層の役割をあらわすクラスとしてLayer Supertypeを持ち、共通の操作が定義されていることが多い。

リモート／非リモート
Service Layerをリモート対応にするには、思った以上にコストがかかるので、安易にリモート化するべきではない。特に、UIがリッチな場合やDomain Modelが複雑な場合は変換やマッピングが面倒くさい。
Fowlerのおすすめは、まずはローカル呼び出し用としてService Layerを作成し、リモート化したければRemote Facadeを追加する、というアプローチ。

いつ使う？
Service Layerのメリットは、多くの種類のクライアントに対して共通の操作セットを提供でき、内部的に呼び出される複数の操作をとりまとめることができる点。 後者は特に、複数リソースをトランザクションとしてまとめる場合などに使われる。よって、これらの要件が存在する場合がService Layerの使いどころになる。
逆に、これらの要件がない（1クライアント/1リソース）のであれば、無用なコストを発生させるだけなので使う べきではない。Page Controllerが直接Data Source層を呼び出す形でレスポンスを構築し、トランザクションをコントロールしてもかまわない、らしい。ここまで言い切ってしまうのが面白い。

雑感
結局、アプリケーションロジックの実装場所、というのが一番理解しやすい。アプリケーションロジックを中立的に実装する場所としてService Layerがある、と考えれば、複数クライアントや複数リソースがないのであればアプリケーションロジックをPage Controllerに実装すればよい、という考えも納得がいく。