arclamp.jp アークランプ

このブログにしては、熱く盛り上がる「賢いデータは必要なのか」。コメントが長くなってきたので、ここで、これまでの議論を整理をして別エントリで続けようと思う。

まず、僕の提示は、

ビジネス（エンタープライズシステム）においては、「データと振る舞いを分離する」手法が、「データに振る舞いを持たせる」手法よりも有効である。　（いろんなところの話を総合）

ということだ。その理由として、前エントリで、次のように書いた。

yusuke： ことビジネスや業務については、賢いデータが存在しているとは思えない。結局、ビジネスや業務というものは、所詮、紙を基本としており、それを動かすことによってなりたっている。紙に必要事項を記入し、窓口にもっていく。窓口の人は、手続きに従って、その紙を処理する。であれば、システムも、そう作ったほうが、あきらかにわかりやすいのではないだろうか？

一方、それと異なる意見の方々は、この手法を、

通りすがりさん： オブジェクト指向のもととなっている抽象データ型に対する視点が抜けているように感じられます。

satoさん：
yusukeさんのおっしゃるデータと振舞の分離は、マーチン・ファウラーの言うところの「Transaction Script」パターン（あるいはドメインモデル貧血症）に相当するかと思います。ファウラーがなぜこれを良くないと言っているかというと、結局これはスクリプト的なプログラミングでしかないので、いずれドメインロジックがある程度の規模になると、コードの重複がどうしても排除しきれなくなる、ということだったかと思います

ハマさん：
通りすがりさんがおっしゃるように、データと振る舞いを分けるのはマーチンファウラー曰く Transaction Script と言われます(ちょっと違うニュアンスですが)。
Transaction　Script だと、似たような処理が重複して出現することが多々あります。処理が重複するのは、オブジェクト指向プログラミングでわないと考えます。

そして、

通りすがりさん： 紙なんてものは、ある事象のビューに過ぎないと考えます。 ドメインモデルを使うことで事象そのものを表現することができるのですから、 わざわざ紙(ビュー)を持ち出さずとも事象(ドメインモデル)だけで表現すればいいではないか、 私はそう考えています。

satoさん：
ファウラーがより優れたパターンとして提案しているのが「Domain Model」です。これは正にデータと振舞を合わせたオブジェクトによって、ドメインを構築する手法です。データと振舞が一緒になるので、ドメイン分析によりしかるべき場所に振舞が置かれるようになり、コードの重複が無くなると言っています。

という解決策をご指摘いただいた。
データと振る舞いを分離してしまうと、実装上のデメリットが大きすぎるということであり、その解決にはデータに振る舞いを持たせるほうが良いという内容かと思う。
もちろん、フォントを扱う場合など、データに振る舞いを持たせたほうが良い場合もある。しかし、どちらを基本とすべきかという点では、大きく異なっているようだ。
意見の相違点を象徴しているのは、次のコメントだろう。データに振る舞い派では、

通りすがりさん： また、仮に「ドメインモデル」が「紙モデル」と比べて不自然なモデルだったとします。 その上で以下のどちらかを選べと言われたならば、私は後者(ドメインモデル)を選びます。 -紙をベースにした、自然だが抽象データ型のメリットを得られないモデル -ドメインモデルをベースとした、不自然だが抽象データ型のメリットを得られるモデル 多少不自然であろうが、ビジネスの現実でなかろうが http://www.atmarkit.co.jp/fdotnet/bookpreview/codecomp2nd_06/codecomp2nd_06_07.html で上げられているメリットを享受できるのであれば、それはそれでハッピーです。

通りすがりさん：
状況に応じてはトランザクションスクリプトの方が有効な場合もあると考えます。

一方、データと振る舞い分離派は、

yusuke： そもそも、ドメインモデルが、実装手法として良いものだとしても、多くの人にとって敷居が高いのであれば推奨できないです。であれば、わかりやすい「データと振る舞いの分離」を前提にしたうえで、抽象データ型のメリットを得る方法を考えたほうがいいかなと。

yusuke：
DIやAOPがある現状では、データと振る舞いを分離しても、十分に実用的な実装メリットが得られるようになったと僕は感じています。

となっている。どちらを選択すべきかという点については、

itakさん： 何が関心事なのか、どの程度複雑と感じるかは人によって異なってくると思いますので、結局誰のために作るか？で決まる気がします。

という意見もいただいた。

さて、前エントリへのコメントでは、「データと振る舞いを分離した場合の実装上のデメリット」というのに焦点が当たった。確かに、データに振る舞いを持たせる場合にくらべて、デメリットが発生する可能性が高いのは間違いない。それが、僕が言うように実用的なレベルに収まるかどうかを、現実的な例もないまま議論しても不毛だろう。なので、一旦、置いておきたい。

逆に、僕が提示した「データと振る舞いを分離」のメリットは、ビジネス分析から実装への理解の明快さである。逆に言えば、「データに振る舞いを持たせる」場合に、ようは抽象化モデリングによって、理解が難しくなってしまうというデメリットが発生しているといえる。
これについては、Seasarプロジェクトの中心人物であり、「くーすー」を提示する比嘉氏が、MDAの幻想というエントリで、

ものごとを抽象化する能力というのは、スキルを必要とします。だれもが出来るというものではありません。しかし、誰もが出来ないことを出来るのが正しいことかというとそれもまた違います。抽象化した概念が正しいなんてことは誰も分からないのです。

だとしたら100人中小数の人しか分からない抽象的なモデルより、100人全員が分かる現実を模倣したモデルのほうが、分かりやすいだけでなく、メンテナンス性にも優れます

としている。
加えるなら、現在、システム開発で重要なのは「育てられる」ということである。ビジネスは常に変化する。であれば、それにあわせたシステムも継続的に変化しなくてはいけない。そのためには常にメンテナンスを行う必要性がある（開発が継続すると表現しても良い）。
その場合に、メンテナンスの主人公となるのは顧客企業の情報システム部門だ。彼らは技術的に高いレベルにあるわけではないがビジネスをよく理解している。そういった方にメンテナンスをしてもらうには、わかりやすいコーディングのほうが効果が高い（MDAがあれば良いなんて幻想は言わないで欲しい）。
こういった視点からいえば、データに振る舞いを持たせることにこだわらず、むしろ手続き型の分かりやすさを取るべきだ。もちろん、その場合に実装デメリットが大きくては意味がないので、オブジェクト指向のテクニックは活用すべきだろう。O/Rマッピング、DI、AOPは大きな力になる。

「データに振る舞いを持たせる」方が、実装上のメリットが大きいことは正しいと思う。では、上記のような視点については、どうお考えだろうか？もし、意見があれば、ぜひコメントをいただきたい。もしくは、yusuke [at] arclamp.jpまでメールをいただければと思う（許可を得ずにBlogには掲載しない）。