エンジニア視点のエントリではあるが、ソフトウェア工学という学術の世界と、ビジネスという現実の世界には、どの分野でも思った以上の深い溝があるのかもしれない。まず、オブジェクト指向の定石というものを考えてから、ビジネスとの不整合について考えていきたい。
データと振る舞いの分離
まず、オブジェクト指向の基本である"データと振る舞い"の一体化ということについて考えてみる。よく初心者本には、「オブジェクト指向とは、関連するデータと振る舞いを１つのクラスに実装する」ことだと書かれている（こんな難しい言い回しはしないかもしれないけど）。これにより、あるデータに関する責務を１つのオブジェクトに与える。たとえば、発注というビジネスがあれば、発注先、発注商品といったデータと、発注する、キャンセルするといった振る舞いを、Orderというオブジェクトに実装する。
ところが、現在流通している多くのデザインパターンが、これを否定しているのではないだろうか。Web側ではStrutsのMVCしかり、DIコンテナ側では様々な実装パターンしかり、どれもデータと振る舞い分離を促している。発注であれば、発注データを持ったValueObject（値オブジェクト）を、発注Facadeのメソッドに渡すという方法になる。POJO（Plain Old Java Object）という考え方も、属性に対するGetter/Setterを基本に、あとは単純な振る舞いぐらいしか実装しない。もちろん、データと振る舞いを分離するかどうかは、最終的にはアーキテクトの設計の考え方や手法にもよる。ただ、強く推奨されているのは、確かだろう。
ビジネスプロセスという現実
こうした流れが出てきたのは、現実のビジネスプロセスを見つめたときに、データと振る舞いの一体化には無理があるということではないだろうか。
まず、振る舞いが単一のデータが管理できる範囲にない点だ。ビジネスプロセスというのは、１つのオブジェクトですむなんてことはまずなくて、たくさんのオブジェクトの関係の上に成り立っている。そのため、そもそも１つのオブジェクトに、あるプロセス全体の責任を負わせることなんかできない、あるいは負わせてしまうと重責（クラスが大きくなりすぎる）になりがちだ。だから、ロジックだけを担当するクラスがあり、InjectされたDAOを使いデータを参照・操作するというのが分かりやすい。
さらに、UI（ユーザーインターフェース、入力方式）をプロセスが分離されている点だ。つまり、どんなユーザーインターフェースであろうとも、あるプロセスにとって入力される伝票（データ）というのは決まっているものだ。発注するには、商品と数と納期が必要だとわかっていれば、その情報を人間が勘で手書きで入力しようが、過去のデータからの自動予測でデータが入力されようが、あるいはその組み合わせであろうが、すべて同じビジネスプロセスで処理されているはずだ（すべきだ）。つまり、システム化する場合にも、UI層は個人に最適化されたフォームが必要だが、ロジック層は単一でかまわないことを示している。これってMVCのことである。
SOAの可能性
一方、SOA（サービス指向）というものを考えてみたい。
SOAの基本は、サービスの利用者と提供者が、ブローカーを通じてやり取りをするだけのものだ。その際、利用者は、提供されるサービスに対して、あるパラメタを渡せば、結果としてなんらかの返値が得られる。なお、パラメタの受け渡しは値だけのオブジェクトモデル（ValueObject）によって行われる。サービス指向ではデータはネットワーク上で転送されため、メモリ内での転送に比べてコストがかかってしまう。そのため、最低限のデータでやり取りすることが必要になるのだ（壮大な理想に立つと、グリッドコンピューティングの世界に入るが、そういうのは無視）。
しかし、ビジネスの流れに対してSOAの概念がフィットすることは間違いない。前述した「データと振る舞いの分離」と「UIとプロセスの分離」というのはSOAの基本的な考え方だ。つまり、あらゆるアプリケーションにSOA"的"な発想が必要だと考えることができる。
ところが、現在、SOAというと、ESB、BPMなどのエンタープライズレベルでのEAI系の流れが中心になっている。
このブログでも何度か書いたように思うのだが、SOAは、もっとロー・ミッドレンジのアプリケーションで考えるべき話題なのではないだろうか。ま、SAOという言葉が気持ち悪いなら、プロセス指向とか、そういう言葉を使っても良い。
まとめ？
なんだか、まとまりのないエントリなのだが、ようは、オブジェクト指向という呪縛を忘れて、ビジネスプロセスを見つめると、常識だと思っていたことが、そうでないと気づくのではないかと思う。
１つだけ、強く思うのは、重要なのはデータではなくて、プロセスだということだ。柔軟に変化するのは、プロセスだけではない。データも柔軟に変化する。プロセスから、システムを考えると新しい世界が見える気がする。ま、とりあえず気だけ。
コメント (9)
Ｕです。
いつもいつもＴＢしてすみません。
コメントだと長くなるので、ＴＢ形式にしています。
わたしゃ自身レベルが低いのにコメントし申し訳なく
思いつつ、誰もが最初はわからないのだから、勉強する
気持ちはあってもいいんだと言い聞かせＴＢしております。
わたしゃのＴＢには無反応で構いませんので…
失礼します。
投稿者: Ｕ | 2005年01月15日 13:06
日時: 2005年01月15日 13:06
はじめまして。濱田といいます。
ビジネスと言っても種類は広いと思います。例えば、アマゾンのような流通系から、証券のようなもの、形もさまざまです。
僕も、オブジェクト指向はビジネスにはむかないこともあると思っています。ただ、鈴木様の言われるのとは逆に、プロセスよりもデータを大事にしているビジネスもあるからだと思っています。
例えば、流通なんかはデータの流れや加工のほうがプロセスよりも重要視されている気がします。モデリングを行う上でも、データを最初に見つけて、新プロセス(新しいビジネス)を見つけ出す順で行うこともあります。(DOA見たいな考え方)
ある側面では、データよりもプロセスが重要なビジネスもあると思います。その場合はプロセス指向のような考え方をするのは大歓迎です。
つまるところ、ビジネスの形を見極めてそれにあった開発手法や考え方をとる能力を付けるのも大切だという意見です。
長くなりましたが、決して意見を否定するつもりはありません。色々な意見交換など出来るといいと思っています。失礼します。
投稿者: ハマショウ | 2005年01月16日 22:12
日時: 2005年01月16日 22:12
arclamp.jpのyusukeです。濱田さん、コメントありがとうございます。
>つまるところ、ビジネスの形を見極めてそれにあった開発手法や考え方をとる能力を付けるのも大切だという意見です。
もちろん、おっしゃるとおりですね。その一環として、オブジェクト指向の基本だけを忠実に守る必要性もないかなという感じです。
>例えば、流通なんかはデータの流れや加工のほうがプロセスよりも重要視されている気がします。
僕自身としては、"データの流れや加工"もプロセスに含まれており、データとは、まさにデータベースの項目を指すつもりです。
もっとも怖いのは、項目を先に決めてしまうことで、プロセスを考える場合に固定観念が生まれてしまうことです。そうなると、かなり後になってから出ないと設計ミスに気づかないことがあります（経験上）。項目の決定を、なるべく遅らせるべきだという感じでしょうか。
実際には、RDBMSを使用する制限もあるので難しいところですがね。
投稿者: yusuke | 2005年01月17日 11:22
日時: 2005年01月17日 11:22
> POJO（Plain Old Java Object）という考え方も、
> 属性に対するGetter/Setterを基本に、あとは単純な
> 振る舞いぐらいしか実装しない。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?POJO
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel
を見る限りは、POJOにそのようなニュアンスは無いように思うのですが。
投稿者: 通りがかり | 2005年04月20日 15:22
日時: 2005年04月20日 15:22
arclamp.jpのyusukeです。確かに、僕の言い方は変ですね。
> 属性に対するGetter/Setter
そいつは、DTO（Data Transfer Object）というやつです。で、POJOは、Getter/Setterという観点ではなく、シリアライズ可能で、継承もない単純なJavaクラスというぐらいでしょうか。そもそも、あまり明確な定義はないような気もします。
投稿者: yusuke | 2005年04月20日 19:07
日時: 2005年04月20日 19:07
シリアライズの可不可はPOJOの要件でないように思います。DTOならシリアライズ可でないと困りますが。
また、継承もないような単純なクラスというのもPOJOの要件ではないように思います。ファウラーはPOJOでドメインモデルを作るのが好みといっていますが、ドメインモデルが単純で継承もないようなクラスということはありえませんから。
投稿者: 通りがかり | 2005年04月21日 05:59
日時: 2005年04月21日 05:59
なるほど。うーん、では、僕は完全に勘違いしていました。"PlainでOld = 単純"という解釈だったのですが。となると、ファウラー氏が、EJBとPOJOを対比しているポイントは、どこらへんになるんですかね？コンテナが不要とか？開発するという意味では、DIできて（Injectする・される）、単体テストしやすければ、それでいい気もします。ていうか、それがすべてな気もしてきました。すみません、自分のブログで聞いてばっかりで。
投稿者: yusuke | 2005年04月21日 09:35
日時: 2005年04月21日 09:35
http://www.theserverside.com/articles/content/FowlerPatterns/Fowler_ch09.pdf
↑の中では
-コンテナ不要
-CMPなEntityBeanでドメインモデルを実現する際に以下が制限となる
├リエントラントでない
├限定されたO/Rマッピング
└粒度の細かいオブジェクト群をリモートで扱おうとするとパフォーマンスに甚大な影響を及ぼす
などをあげているようです。
投稿者: 通りがかり | 2005年04月22日 12:33
日時: 2005年04月22日 12:33
なるほど。やはり、EJBの対語として考えたということですね。モデルに、適切なデータと振る舞いを持たせるためには、EntityBeanでは扱いにくいということですかね。POJOであれば、融通が利くと。
ただ、僕自身が、DTOとサービスだけ（ファウラー氏がいう、 Transaction Scripts）で実装して、なにがいけないのかわかっていないので、エントリのような発言になったのだと思います。つまり、POJO＝DTOだという思いですね。ちょっと、ドメインモデルということから、勉強しなおします。
投稿者: yusuke | 2005年04月25日 01:22
日時: 2005年04月25日 01:22