長年、邦訳されなかった「思慮深いソフトウェア開発者全員の必携書」

長年、邦訳されなかった「思慮深いソフトウェア開発者全員の必携書」

　「Domain-Driven Design」通称「DDD」の原著が出版されたのは、2003年のことだった。Kent Beck氏が賛辞に寄せた「思慮深いソフトウェア開発者全員の必携書」という言葉が示している通り、英語圏では圧倒的な支持を集め、出版から7年が経過した現在でも、Yahoo! Groupsのメーリングリストでは活発な議論が交わされている。

　一方、日本では少し状況が異なる。識者の間では、有用な書籍として早くから知られていたものの、500ページ超という厚さと、文体の難しさが、多くの日本人エンジニアの挑戦を阻んできた（邦訳も待ち望まれたが、長い間出版されなかった）。

　佐藤匡剛氏による「Domain-Driven Designのエッセンス」、徳武聡氏による「DDD Quickly 日本語版」をはじめ、日本語の情報は少なからず存在したし、国内での実践事例も徐々に蓄積されていたものの、本質的にはある種の膠着状態が続いていた。

　そうした中にあって、4月8日のDDDの日本語訳刊行、4月12日のQCon TokyoにおけるEric Evans氏の講演、さらに翌13日のEvans氏によるDDD1日チュートリアルの開催という一連の流れは、日本のDDD受容にとって大きなブレイクスルーであったと言えよう（この重要な書籍の翻訳に関われたことは、筆者にとっても大きな喜びである）。

　ここで、QCon TokyoでのEvans氏の基調講演を振り返ってみよう。Evans氏によれば、ソフトウェアにおける「複雑さ」は、そのソフトウェアが対象とするドメインそれ自体の中にある。ドメインとは、ユーザが知識を持ち、活動する対象の領域のことである。日本語にすれば、「業務領域」とも言えよう。一方、モデルは、ドメインの中から選び出された特定の側面を表現するための、抽象の体系であるとされる。このドメインがシンプルであれば、ドメインモデルを作る必要はない。しかし、多くの場合、ドメインにはモデリングするべき複雑な領域が存在する。

　具体例として、Evans氏は、書籍の中にも頻繁に取り上げられる貨物輸送システムを用いて、ドメインの中に複雑なロジスティクスが存在することを示す。こうしたモデルを作ることについて、Evans氏は「リアリズムではない」と語る。モデルは現実をそのままに映しとるものではなく、特定の目的に対して役に立つことを意図されたものなのだ。

　これを説明するために、Evans氏は地図を例に挙げる。メルカトル図法で書かれた地図において、グリーンランドとアフリカ大陸はほぼ同じ大きさであるように見える。だが現実にはアフリカ大陸の方が15倍大きい。これは、球体である地球を平面に投影した結果発生した「ゆがみ」である。しかし、メルカトル図法には重要な特徴がある。地図上の2点を直線で結んだ際の緯線に対する角度は、実際のものと同じになる。つまり、メルカトル図法で書かれた地図は、実際の「航海」という目的に対して役立つように作られたモデルなのだ。

　メルカトル図法の核心は、球体上のある点を平面にマッピングする関数である。この関数に対して地理データを入力すると地図が出力される。関数が同一でも、入力されるデータが異なれば、結果として現れる地図は異なったものになる。例えば、Evans氏が紹介した16世紀に描かれた地図。ヨーロッパ、アフリカからアジアにかけては比較的正しく描かれているが、アメリカ大陸の情報は少なく、オーストラリアに至ってに描かれていない。ただ、その地域に「何かがある」ということがうっすらと認識されていただけだ。同じように、我々がソフトウェア開発に取り組むときにも、あらゆる領域の情報が揃っているわけではない。我々の作るモデルも、濃淡のある情報を元に作られるものなのだと、Evans氏は語る。