「サービス」と「処理」

今年の5月に、「オブジェクト指向とは何か」という記事を書いた。
そこで、最後に、以下のような疑問を呈している。

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

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

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

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

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

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

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

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

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

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

「サービス」と「処理」” に対して 0 件のコメントがあります

  1. Jan より:

    「オブジェクト指向とは何か」を読みました。
    「オブジェクト指向」は、間違いなく正しい概念でしょうね。「モデリング」で「グループ分け(クラス洗い出し))」と「役割分担(データとメソッドの振り分け)」を
    行う所まではぜんぜん問題ないと思います。
    問題はどう実装するかでないしょうか?ここからは、自動生成ありきで物事を考えていきます。
    個人的には、モデリングツールから自動生成でソースに落とす場合を考えた場合、
    メソッド内の処理はモデリングツールで記述できない。よって、別の場所で記述した方が
    良いような気がします。(ドメインの中にはビジネスロジックを記述しない)
    ・ Domain
    ・ Dao
    ・ マッピングファイル
    ほぼ、生成できるでしょう。少し、問題ありますが。。。
    ただ、ビジネスロジックを外出しするなら、サービス内にじかに書くというよりも、
    もう1つ新しい概念が登場しそうですね([ビジネス]かな?)
    [ビジネス]のクラス(commandパターン) ← モデリングで摘出したメソッドごとに1つのクラスができるのかな。
    もうちょっとグループ化できそうですけど。。
    これぞまさしく、ネオオブジェクト指向(NEOOO=ネ・トリプロオー)ですかね。。

  2. inoccu より:

    コメントどうもです。
    自動生成を前提に考えると、たしかにそうなると思います。
    自動生成と言われて真っ先に思いつくものに、MDAがあります。
    そこでビジネスロジックの自動生成をどうやるかというと、UML2.0で書いたシーケンス図とかを元ネタにするわけです。(ご承知のとおり)
    しかし、そんな複雑なシーケンス図を描くことにどれだけの意味があるのか?
    マーチン・ファウラーあたりも指摘しているように、たしかに疑問に感じます。
    となると、ビジネスロジックはコーディングする(ご指摘のビジネスという概念のコンポーネントかもしれません)のが最も速そうであって、それは、Javaのようなものではなくて、スクリプト言語的なものが良いと考えています。
    データベースの世界では、言語に囚われず、比較的簡単に習得できるものとしてSQLが一般的になりました。
    そういう感じのものが、ビジネスロジック(つまり振る舞い)を記述するものとして現れ、一般化する世界が来たら良いと思います。
    例えば、OCLがもっと拡張されたようなイメージでしょうか。

  3. Jan より:

    プログラム書く時代が終わりそうな気がします。
    ただ、ビジネスロジックはまだまだコーディングするでしょうね。
    今、こだわってるのは、ビジネスロジックを置く場所です。
    モデリングで摘出した「データ」+「処理」を別の場所に定義するのもありじゃないかと。
    1. Domain内には、ビジネスロジックはおかない。
    2. ビジネスロジックは[ビジネス]のクラスにおく。
    3. [ビジネス]のクラス(command,strategyパターン)単位は各クラスごとのビジネスロジックごとに1クラス。
    ドメインモデリングで素直にクラスに落とすと、高凝集性は満たせても、
    疎結合性は満たしていない気がしますね。
    ■ ドメインにビジネスロジックがある場合の問題点
    1.メソッドがありすぎて、ビジネスロジックが分かりにくい。
    2.疎結合性が満たされているか疑問。
    3.完璧に設計しないともろい(遊びが少ない)
    4.Generation Gap(自動生成が難しい)
    5.技術者が育ってない。
    ■ [ビジネス]のクラスを用いた長所
    1.ビジネスロジックの存在場所がすぐわかる。
    2.ロジックの一元管理が可能。(汚い物を1つの場所に閉じ込める)
    3.自動生成が可能(Domainは自動生成,[ビジネス]のクラスは手で実装)
    4.わかりやすい。つくりやすい(遊びがある)
    5.オブジェクト指向型技術者と非オブジェクト指向型技術者の融合。
    ようは、([ビジネス]のクラス + Domain)でオブジェクトを表現するってことです。
    概念レベルのモデリングは今までとかわりません。摘出したメソッドの実装場所が
    変わるだけです。

  4. [dev]ドメインモデルあれこれ

    http://digitalmorning.net/?itemid=1156 のコメント欄に ■ ドメインにビジネスロジックがある場合の問題点 1.メソッドがありすぎて、ビジネスロジックが分かりにくい。 2.疎結合性が満たされているか疑問。 3….

コメントを残す