SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

直近開催のイベントはこちら!

EnterpriseZine Day 2022

2022年6月28日(火)13:10

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

Events & Seminars

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

DDD の著者が伝える、モデリングの真の意義~QCon Tokyo 2011 Conference

Kent Beck氏が「思慮深いソフトウェア開発者全員の必携書」と賛辞を寄せ、英語圏では圧倒的な支持を集める「Domain-Driven Design」。長らく、待ち望まれていた邦訳版の出版によって、DDDを取り巻く国内の状況に変化が生じるかもしれない。

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

 「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氏は語る。

次のページ
ドメインの必要な知識は開発を通してしか得られない

この記事は参考になりましたか?

  • Facebook
  • Twitter
  • Pocket
  • note
Events & Seminars連載記事一覧

もっと読む

この記事の著者

和智 右桂(ワチ ユウケイ)

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/3061 2011/04/25 00:00

Job Board

PR

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

2022年6月28日(火)13:10

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング