「サービス」と「処理」

今年の5月に、「オブジェクト指向とは何か」という記事を書いた。

そこで、最後に、以下のような疑問を呈している。

最近出てきた手法や、最新の技術を紹介するような書籍でも、データと処理は分離されている。データと処理のカプセル化というのは、結局理想でしかないのか。この理想は実現できないのか。それが、目下の悩みの種である。

最近、「サービス」という言葉が盛んに使われている。
SOAなどは正に「サービス指向」アーキテクチャであり、その代表格だ。
また、一般的なシステム開発においても、プレゼンテーション層、「サービス層」、パーシステンス層などと3層のレイヤリングが常識だが、ここにもサービスがある。

5月の記事で、データと「処理」は分離されている…と書いたくだりがあるが、流行の「サービス」と、使い古された「処理」は同じ意味だろうか、それとも違うものなのだろうか。

一般的に、3層レイヤリングにおけるサービス層は、その内部にドメインモデルを保持する。ドメインモデルがビジネスロジックを片付けるからである。
それでも、ドメインモデルとプレゼンテーション層の間に（狭義の）サービスが存在する。この（狭義の）サービスは、ファサード的な位置づけで、薄い層にすることが良い設計とされる。

しかし、Seasarでいうダイコン時代の設計は、サービスを厚くする。ドメインモデルはデータと処理に解体され、処理はサービスに吸収される。データはEntityとして、DTO的にパーシステンス層に吸収される。
パーシステンス層のフレームワークであるS2Daoが、Hibernate的なものではない所以だ。

ところで、SOAにおけるサービスは、どのようなアーキテクチャで実装するのだろうか。
粒度の違う話をしようとしているのは、承知の上である。
SOAは、基本的に連携部分にフォーカスした技術であって、サービス内部の実装を云々いうものではないとも思っている。
しかし、敢えて続けると、SOAのサービスはその外壁部のファサードが連携のインタフェースを担い、内部ではドメインモデルが活躍しているのだろうか。

さらに話を飛躍させると、SOAにおけるサービスの粒度は少なくとも小さいものではないとされているが、それは何故だろうか。
もし、EJBでの粒度論のように、ネットワーク通信にまつわるパフォーマンスが理由であるとすれば、もしネットワークがコンピュータの内部バス程度のパフォーマンスを持ったとすると、適した粒度は変化を見せるのだろうか。
もし、その粒度が小さくなったとすれば、サービスと処理の違いは何だろうか。（言葉の定義として、サービスはある程度大きく、処理はある程度小さいとした場合）

何らかの答に到達したわけではないのだが、データと処理をまとめることを、盲目的にやるべきではないと、感じているのである。
ある程度大きな粒度（サブシステムくらい）においては、データと処理はセットになっていた方が良いかもしれない。
また、相当に小さな粒度（クラス1個分くらい）では、それが持つデータだけで解決できるような処理についてはセットになっておくべきだと思う。

では、その中間（3層レイヤリングでのサービス層の範疇、より具体的には、Webシステムでの1画面遷移分くらいでやることを指す。）だと、どうだろうか。
ここらへんが、一般のアプリケーションエンジニアの腕の見せ所の領域であり、もっとも悩む領域である。

結局、答は見つかっていないのだが…。