2007-06-14

ドメインモデルに対する日米の温度差

テーマ:設計
 マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。

日本ではTransaction Scriptが優勢
 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。

 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ(彼の言い方では「シンドメインモデル」)を提唱している。
 私は、エンティティに振る舞いが割り振られているのが良いオブジェクト指向ではなく、より現実のモデルをうまく写像しているのが良いモデルだと思っています。[...]
 私たちが業務で行っているようなことは、伝票とアクティビティを素直にエンティティとアクティビティ用のインターフェースにマッピングするのがいちばん簡単で変更にも強くなると思います。また本質的なことではありませんがDIと非常に相性が良い。
 エンティティに振る舞いを与えようとするドメインモデルは、現実との乖離があるだけでなく、結構DIと相性が悪いと思います。
― 「業務アプリケーションは結局関数と構造体だけあれば充分?
 日本Springユーザ会などで活躍されているアークランプの鈴木雄介氏も、データと振る舞いの分離を推進する提唱者の1人だ。
今、僕がアプリケーションを組むなら、間違いなくデータと振る舞いを分離してしまう。まず、ビジネスロジックと言われる部分で、データをどう扱うのかという振る舞いを記述する。一方、データを保持するクラスは、Getter/SetterだけのJavaBeansにしてしまい、なるべくそれ以外のメソッドは実装しない(データ構造だけに関係あるメソッドならOK)。
[...]
たぶん、ファウラー氏が主張するようなドメインモデリングは、データに振る舞いを持たせることを基本にしている。ユースケースから抽出されたものを、ドメインモデリングして、整合性を確認している。しかし、そんな顧客が理解できないようなモデリングに意味があるとはどうしても思えないのだ。
― 「賢いデータは必要なのか
少なくとも日本のDIコンテナのコミュニティでは、このようにアプリケーションをデータ(DTO or エンティティ)と振る舞い(サービス)に分けるアーキテクチャが好まれており、実際にそういうアプリケーションをよく目にする。

 日本でTransaction Scriptを推奨する意見の大半は、次の3点に集約されると思われる。
・ (日本の)ビジネスでは、データと振る舞いを分けた方が自然にモデル化できる
・ ドメインモデリングは修得や理解が難しく、プログラマの確保が難しい
・ Domain ModelよりもDIとの親和性が高い
 私自身、開発現場では主に2番目の理由から、現実路線としてTransaction Scriptを積極的に採用する。(OO厨なので、自分だけで好きにやるときはDomain Modelを使うようにしているのだけれども・・・)

しかし、海外ではDomain Modelパターンが熱い
 ところが、海外ではDomain Modelパターンが大人気だ。たとえば、Spring開発者のロッド・ジョンソン氏は、今後のJava開発が進むべき道として、
- True objects (真のオブジェクト)
- Rich domain models (リッチなドメインモデル)
を挙げている(InfoQの記事)。Domain Modelパターンを実践するアプローチである「ドメイン駆動設計」も、評価が定着し色々なところで参照、利用されている。今をときめくRuby on RailsもActive Recordをベースにしているので、その基本的なアーキテクチャはDomain Modelが前提になっている。
 逆に、Domain Modelを批判する意見はほとんど聞いたことがない(少なくとも、私が海外のニュースやブログを読んでいる限りでは)。

(6/17 追記: Ted Neward氏*1"The Vietnam of Computer Science"(コンピュータサイエンスにおけるベトナム戦争)というブログ記事を書いているが、あるいはこうした意見をピュアOOに対する批判と捉えることもできるかもしれない。この記事は、O/Rマッピングツールはベトナム戦争と同じようにインピーダンスミスマッチに対する終わりの見えない戦いだとしており、OOを捨てるか、逆にOODBを採用するなどの代替案を考えるときが来ているとしている。O/Rマッピングは本来Domain Modelのための永続化ツールなので、O/Rマッピングに疑問を投げかけることは、ある意味Domain Modelに疑問を投げかけることでもある)

*1 オライリーやAddison-Wesleyで、JavaやC#などの本をたくさん書いている人。

 理論的に見れば、オブジェクト指向の良さは既に実証されている訳だが、それをみんなが楽観的に信じているような雰囲気がある。日本の現場的なペシミズムと違い、理屈として良いものは実際に良いはずだし追求されなければならない、という信念があるかのようだ。

 どちらが良い悪いという話ではなく、そもそもそんなことを議論しても不毛なだけだろう。ここで注目したいのは、単純に、日本と海外でのドメインモデルに対する、はっきりとした温度差である。

なぜ温度差があるのか?
 どうして日本と海外とでは、ドメインモデルに対してこんなに温度差があるのだろうか? たぶんこの疑問に、簡単に答えを見つけることはできない。

 今はただ、これと似たような話として、ERPパッケージの導入に関する日本と海外との違いを思い出す。海外に比べて、日本ではERPの導入はなかなか普及しないらしい。海外では人がシステムに合わせればいいという考え方があるため、標準設定のままで導入できることが多いが、日本ではあくまで既存の業務のあり方は変えず、システムを人に合わせなければならないため、大量のカスタマイズが発生してしまうからだという。
 ERPの導入には、自社のやり方を業界標準に合わせることで合理化を図るという、業務改革の意味合いもある。海外の企業は、そうした業務改革も含めてERPの導入を推進するが、日本の企業はあくまで既存の業務を温存し、後々アップグレードのコストが高くつくにも関わらず、あえてパッケージのカスタマイズを要求する。

 SOX法への対応でも、同じような話を聞く。海外企業は業務改善の機会と捉えて、積極的にSOX法への対応を行なうというが、一方の日本企業は、J-SOX法対応をあくまでネガティブコストとしか捉えず、最小限の労力しか割きたがらないらしい。

 これと同じようなメンタリティが、ドメインモデルを巡る部分にもあるのかもしれない。高度なオブジェクト指向のスキルをプログラマに身に付けさせるのには、当然相応のコストがかかる。しかし、そのコストに見合うだけの見返りはある。もしOOのパラダイムシフトを身に付けていない現状を肯定してしまえば、そこでの最適解はTransaction Scriptになる。ただし、それは局所解でしかないだろう。
 新卒プログラマ100人のチームで開発したいのか、ケント・ベック10人のチームで開発したいのか。その価値判断の違いが、温度差の原因なのかもしれない。

(ここまでの論旨だとTransaction Scriptに対してネガティブな評価に読めてしまうが、そんなつもりはないのでご理解いただきたい。日本にもトヨタのように卓越した企業はある)

 この温度差が、今後どうなっていくのかが興味深いところだ。Transaction ScriptとDomain Modelのどちらか一方に軍配が上がって、他方を駆逐してしまうのか。それとも、そのままソフトウェア開発における文化の違いとして、定着していくのか。あるいは、日本と海外とでは、ソフトウェア開発が解こうとしている問題の性質が、そもそも異なっていたことが判明するのか(違う問題であれば、当然解決法のパターンも異なってくるはずだ)。


AD
いいね!した人  |  コメント(4)  |  リブログ(0)

ouobpoさんの読者になろう

ブログの更新情報が受け取れて、アクセスが簡単になります

コメント

[コメントをする]

4 ■ビジネス未満ロジックを

こんにちわ。ふと思ったんですが、

「ビジネス」ロジックのOO化を
お客さんが理解できないから忌避する、
ってのをまあ許したとしても、

「ビジネス未満」ロジックのOO化は
理解すべきは開発サイドなんで、
忌避する理由は無い気がしてます。

ビジネス処理より下の層の処理を、です。

例えばDBアクセス処理が典型。

あと、よく言われる「誕生日と日付から年齢を算出」
なんてのまで非OO化つまり受動化してしまったら、
年齢の設定し忘れをやらかすのがオチなんじゃないでしょうか?

リアルでいえば「伝票を手で書く」のは非OO的ですが、
「伝票を書いたらカーボン紙で二重化される」のは
(伝票に)ちょっぴりインテリジェントな機能が追加されてる感じがします。
カーボン紙は自動(自働?)化されてるのが味噌。

そういう道具もビジネス(の隙間)に入る余地が
結構あるんじゃないかな。

少なくとも処理を全く持たないDTOばっかりってのは
やりすぎだと感じてます。
実際人の書いたソースを見るときも
「ここに妥当な値を入れる責任者は誰だ?」と
探すのが大変だったり。

3 ■OOこそ簡単だったはず…

こんにちわ。
顧客が理解できないってのこそ「ほんとかよ?」とか思っちゃってます。説明が下手なだけなんじゃないのか?と。
何の説明かというと、OO(P)でこれからやろうとしてる「見立て」と、お客様の頭の中のかたちとの刷り合わせのです。

それとも、日本の商人はみんな実際の商品からはソッポを向いて、伝票ばっかりと睨めっこしてるってことなんでしょうか?だとすれば今こそ彼らを「バーチャルリアリティは悪である!」と責めるべき時なのではないでしょうか?

冗談はともかく…

(特に日本の伝票ベースの)商人諸氏は、まさにその人そのものがVisitorパターンのVisitorになってるのだろうと思います。きっと良くも悪くも「自分で全部する」人なんです。そしてそれを批判する人はたぶんその悪い面を批判してるんだろうと思います。

私も割りと批判的なほうかな。日本人ってアニメなどの映像化が好きな割には(^^;、仕事になるととたんに「真面目」というか…擬人化という発想の融通が利かなくなるというか…のかなとは思ったりしまてす。

見立てとか擬人化とか、ブーブーとかニャーニャーとか(^^;、OOってそもそもあんまり頭を使わなくてむしろ子供っぽい方法論だと私は思っています(そこが好きです)。それがお客さんに伝わってないのだとしたら、あるいは伝わっても「そんな子供ぽいやり方が出来るか」と蹴られてるのだとしたら、いちOOファンとしては残念だなと思っています。子供っぽいということは間違いにくいということなのに…。もちろん間違わなくなる「まで」の道つまりモデルの申し合わせは不可欠なのですが。

擬人化は大事だと思うんです。「商品のきもちになって考える」ことになりますから。仕事を「する」という視点(だけ)じゃなく、商品の側から仕事を「される」という風に見るとどう見えるか、を、考えてみることは有意義だと思うんです。

2 ■なるほど

yojikさん、
なるほど。確かに日本ではRDD、CRC、GRASPなどはあまり普及してないですね。言語や技術はほっておいてもいつの間にか普及しますが、方法論や思想は熱心な伝道者がいないと厳しい訳ですね。(その点、XPとかは恵まれていたのかも)
そうすると、温度差の一因は言語の壁にあるのかもしれません。なかなか興味深いです。
(Wirfs-Brockの本は、翻訳出たら買おうと思ってます :) )

1 ■はじめまして

日本では、責務駆動設計が初期の段階であまり紹介されなかったのも大きいと思います。(そういえば弊社で翻訳中のあの本はどうなったんだろ)
そのせいで「単にEntityに振る舞いを持たせただけのモデル」=「ドメインモデル」というイメージで捉えてる人が多かったと思います。(いわゆるオピニオンリーダな人を含めて)
Entityに振る舞いを持たせただけのモデルでは、あまりにもナイーヴ(OO厨)すぎるのは確かで、そこらへんの誤解からドメインモデルは広まらないのではと思います。
最近は日本の状況もかわりつつあるような気もしてますが。

コメント投稿

AD

Ameba人気のブログ

Amebaトピックス

      ランキング

      • 総合
      • 新登場
      • 急上昇
      • トレンド

      ブログをはじめる

      たくさんの芸能人・有名人が
      書いているAmebaブログを
      無料で簡単にはじめることができます。

      公式トップブロガーへ応募

      多くの方にご紹介したいブログを
      執筆する方を「公式トップブロガー」
      として認定しております。

      芸能人・有名人ブログを開設

      Amebaブログでは、芸能人・有名人ブログを
      ご希望される著名人の方/事務所様を
      随時募集しております。