ドメインモデルに対する日米の温度差
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。
日本ではTransaction Scriptが優勢
この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。
たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ（彼の言い方では「シンドメインモデル」）を提唱している。
日本でTransaction Scriptを推奨する意見の大半は、次の3点に集約されると思われる。
・ （日本の）ビジネスでは、データと振る舞いを分けた方が自然にモデル化できる
・ ドメインモデリングは修得や理解が難しく、プログラマの確保が難しい
・ Domain ModelよりもDIとの親和性が高い
私自身、開発現場では主に2番目の理由から、現実路線としてTransaction Scriptを積極的に採用する。（OO厨なので、自分だけで好きにやるときはDomain Modelを使うようにしているのだけれども・・・）
しかし、海外ではDomain Modelパターンが熱い
ところが、海外ではDomain Modelパターンが大人気だ。たとえば、Spring開発者のロッド・ジョンソン氏は、今後のJava開発が進むべき道として、
逆に、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のどちらか一方に軍配が上がって、他方を駆逐してしまうのか。それとも、そのままソフトウェア開発における文化の違いとして、定着していくのか。あるいは、日本と海外とでは、ソフトウェア開発が解こうとしている問題の性質が、そもそも異なっていたことが判明するのか（違う問題であれば、当然解決法のパターンも異なってくるはずだ）。
日本ではTransaction Scriptが優勢
この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。
たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ（彼の言い方では「シンドメインモデル」）を提唱している。
私は､エンティティに振る舞いが割り振られているのが良いオブジェクト指向ではなく､より現実のモデルをうまく写像しているのが良いモデルだと思っています。[...]日本Springユーザ会などで活躍されているアークランプの鈴木雄介氏も、データと振る舞いの分離を推進する提唱者の1人だ。
私たちが業務で行っているようなことは､伝票とアクティビティを素直にエンティティとアクティビティ用のインターフェースにマッピングするのがいちばん簡単で変更にも強くなると思います。また本質的なことではありませんがDIと非常に相性が良い。
エンティティに振る舞いを与えようとするドメインモデルは、現実との乖離があるだけでなく､結構DIと相性が悪いと思います。
― 「業務アプリケーションは結局関数と構造体だけあれば充分?」
今、僕がアプリケーションを組むなら、間違いなくデータと振る舞いを分離してしまう。まず、ビジネスロジックと言われる部分で、データをどう扱うのかという振る舞いを記述する。一方、データを保持するクラスは、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 （真のオブジェクト）を挙げている（InfoQの記事）。Domain Modelパターンを実践するアプローチである「ドメイン駆動設計」も、評価が定着し色々なところで参照、利用されている。今をときめくRuby on RailsもActive Recordをベースにしているので、その基本的なアーキテクチャはDomain Modelが前提になっている。
- Rich domain models （リッチなドメインモデル）
逆に、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のどちらか一方に軍配が上がって、他方を駆逐してしまうのか。それとも、そのままソフトウェア開発における文化の違いとして、定着していくのか。あるいは、日本と海外とでは、ソフトウェア開発が解こうとしている問題の性質が、そもそも異なっていたことが判明するのか（違う問題であれば、当然解決法のパターンも異なってくるはずだ）。