DDDの読書記録（第1部序章、ドメインモデルを機能させる）
先日開催されたQCon Tokyoにて、翔泳社さんのブースでエリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)をTシャツ付きで購入しました。そして、Twitterにて翔泳社の岩切さんと
それで、原著者のエヴァンスさんと翻訳者の一人である和智さんのサインをいただくことができました。本当に感激です、ありがとうございました。（ご愛嬌で和智さんのサイン日が11日になっていますが、実際は12日です。）
ということで、もともと大好きなDDDの本だったのですが、サイン入りということでますます真剣に読書に取り組みたいという気がしてきました。今後日本語版を用いた勉強会も計画されているみたいですが、とりあえず、章ごとに読書記録をつけていきたいと思います。*1
第1部ドメインモデルを機能させる
まずは、第1部最初のページ（P2）の部分に18世紀のものとされる中国の地図の写真が掲載されています。18世紀と言えば清朝の時代ですが、日本では伊能忠敬の実測による地図も既に作られている時代ですし、測量術は既に入ってきていると思いますから、こんな不正確な図が描かれるのだろうかというのが最初の印象でした。おそらく、もっと正確な地図もあったけれど、民衆の間には普及していなかったということもあるのかもしれません。
それで、この絵が第1部の最初に使われている理由は、当時の中国の測量術のなさをdisっているのかと最初思いましたが、良く読んでみると、そういうことが言いたいのではなく、モデルは目的によっていろいろな正解があるということなのかなと理解しています。
この18世紀の中国の地図は、世界全体を表している。中央に配置され、スペースの大半を占めているのが中国で、その周りを囲んでいるのが、おざなりに表現された他の国々である。世界についてのこのモデルは、国内に意識が向いていた当時の中国社会にふさわしいものだった。この地図が示す世界観は、外国人に対応するには役に立たなかったに違いない。もちろん、現代の中国には全く無意味だろう。地図はモデルである。そしてどんなモデルも、現実の何らかの側面や興味の対象となる概念を表している。モデルとは簡素化である。つまり、当面の問題を解決する上で関連する側面を抽象化し、それ以外の詳細を無視することによって行われた、現実に対する1つの解釈なのだ。
エヴァンス氏は、ドメインモデルとは現実をできるだけ「写実的に」に正確に表現することではなく、必要な知識が厳密に構成され、選び抜かれて抽象化されたものと説明しています。だから、たとえば、ある金融商品の知識をできるだけ厳密に表現するのが正しいモデルなのではなく、アプリケーションを実現する上で本当に必要な部分のみを厳選して抜き出したものが有用なモデルなのだとしています。だから、当然同じ業務ドメインでも、目的によって異なる複数のモデルが存在し得るわけですし、一つの究極のモデルが存在するわけではないということですね。*2
オブジェクト指向はもともと現実世界のシミュレーションから入ったとされることもあって、現実世界の正確な描写が目的であると考えてしまったり、究極のモデルは一つであると考えてしまいがちですが、少なくともDDDの思想ではこれは間違いということですね。これはこの本を理解する上で大変重要なポイントになると思います。
ドメイン駆動設計におけるモデルの有用性（P3）
ドメイン駆動設計では以下の３つの基本的用法によって、どのモデルを選択するのかが決定されるとしています。
モデルと設計の核心が相互に形成し合う
この項目のタイトルは原書では「The model and the heart of the design shape each other」なのですが、この項目内の説明でモデルと実装が密接に結びつくことが大切と説明しています。ということは、
the heart of the design = 実装コード
の関係を暗示していることになりますね。実際、heart of the designの前に定冠詞のtheがついていることから、設計の核心となる特定の対象が存在していることを表していますから、これは実装ということが容易に類推できます。日本語訳だとちょっと見落としがちですが。これは、私が以前にプログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指してで書いたこととつながっているのかなと思いました。結局、モデルはコードを単純化するものであってほしいし、逆にコードを読んだだけでモデルが頭に思い浮かぶようなものが理想的なのだと思います。逆に、上流の人がUMLできれいなモデルを作成したけれど、PGの作成したコードはスパゲティーだったなどということがあってはいけないし、そんなモデルは存在価値がないということです。（第3章でモデルと実装の結びつきについては説明されている）
モデルは、チームメンバ全員が使用する言語の基盤である。
これは第2章のユビキタス言語につながってくる考え方で、プログラマーとドメインエキスパートが共通の言語で会話できるようになるということですね。ここは日本人だと間に英語が入ってくることが普通（主要なプログラミング言語が英語を使った時に最も自然なため、多くの日本人がオブジェクト指向プログラミングを苦手とするのは英語アレルギーだからか？ - 達人プログラマーを目指して）で、通常英語と日本語との間では単純な一対一のマッピングできないことが多いため、実際かなりハンディキャップがあると個人的には感じるところです。
モデルとは、蒸留された知識である
これは地図の話にも関係していると思いますが、必要なエッセンスを蒸留したものがモデルであるという考え方です。（第1部の範囲では第1章のテーマ）
ソフトウェアの核心（P4）
このセクションでもDDDを理解する上で非常に重要なことが書かれていますね。つまり、
ソフトウェアの核心（The heart of software）はドメインに関係した問題をユーザの為に解決する能力である。
と書かれています。だから、ユーザーインタフェースやツール、フレームワークなどの純粋に技術的な問題はもちろん重要だけれども、最終的に金融や流通などの業務ドメインの問題を解決するというところこそが心臓部なのだということです。日本のSI業界だと特にPGの単価が最低に押さえられているし、上流と下流で担当者が明確に分離されているということもありますが、一般的に優秀なプログラマーが個別の業務ロジックを作るなどということは到底考えられません。仮に、優秀な技術者を確保できたとしても、基盤フレームワークのチームなど汎用的な部品の作成などにまわされてしまうことが普通です。実際、SEの神様と崇められているような人からも
（注意、これはDDDからの引用ではありません。）
アプリケーションプログラムを書くIT技術者（俗に言うプログラマ）は筆者の定義ではSEではない。それは，一般のプログラム作りは付加価値のある仕事とは言い難いからだ。
などと言われ*3、いまだに多くの人からそういうものだと信じられているというところがあります。（上流の壁？ - 達人プログラマーを目指して）
また、日本だけでなく、プログラマーの地位が高いとされる外国でも、多くの場合、金融などの業務知識のモデリングスキルを伸ばすことよりも、最新の言語やツールの方に興味の対象が向いてしまうという傾向はもちろんあります。映画の撮影のカットでコートの袖が一瞬写り込んだことによって、専門の映像編集者によって面白いシーンがカットされてしまったという話がたとえ話として出てきますが、ソフトウェアプロジェクトでは専門性も行き過ぎると弊害になるということを筆者は教訓として出しています。
本書では、ドメインの開発には非常に高度な設計スキルを養う機会があふれていることを示していく。ほとんどのソフトウェアドメインにおけるこの混沌とした状況は、実は、興味深い技術的な課題なのである。実際多くの科学分野では、「複雑性」が最も刺激的な最新テーマの１つであり、研究者たちは現実世界の混沌に取り組もうとしている。ソフトウェア開発者も、まだ形式化されたことのない入り組んだドメインに直面した際には、同じ立場に立つことになる。その複雑さを一刀両断する明快なモデル作り出すのは、刺激的な作業だ。
つまり、単に新しい技術を使うということだけでなく、複雑な業務上の問題を賢く解決するための方法を考えつくというのが業務プログラマーが最も能力を発揮すべき領域だとしています。もちろん、Web系やゲーム、ツール作成なども広い意味でドメインの一つだし、そういう領域のプログラマーもDDDの対象として含まれます。ただし、それ以外の業界であっても、業界構造が海外のようなあるべき姿にリファクタリングされれば、本来はプログラマーが非常に面白い、創造性豊かで高付加価値の仕事ができる可能性があるということだと思います。
*1:DDDの読書会の記録も参考なります。DDD - Java EE勉強会
*2:MVCパターンなどでいうモデルとは複数のビューに対して一つのモデルがあることを示しているわけですが、ドメインモデルとは現実世界から目的に応じて必要な部分を抽出したビューの一つということもできるかもしれません。
*3:http://itpro.nikkeibp.co.jp/article/Watcher/20060829/246743/
