 |
[2007 年 7 月号] |
［技術講座］
DDD難民に捧げる
Domain-Driven Designのエッセンス
第1回 ドメイン駆動設計とは
株式会社オージス総研 アドバンストモデリングソリューション部
佐藤 匡剛
 |
Domain-Driven Design Eric Evans 著 |
「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「ソフトウェアの真の複雑さに挑戦する」という副題からも分かるように、ドメインモデリングに正面から取り組んだ待望の書籍です。
DDDは、海外では非常に評判の高い書籍です。本書の出版前からMartin Fowler氏により「期待できる内容だ」と推薦されていたり、GoFの1人であるRalph Johnson氏は自身のブログで本書を「4、5回は読み直した」と賛辞を送っています。Spring Frameworkの開発者Rod Johnson氏も、最近のプレゼンテーションでDDDを紹介しながら、「Java EE開発者がこれから進むべき道はリッチなドメインモデルだ」と発表しています。また、MDAツールSculptorのように、DDDを積極的に採用したツールやフレームワークも登場しつつあります。
しかし、日本では翻訳書がいまだに出版されていないこともあり、本書の出版から3年近く経った今でも、まだまだ一部の通の人たちにしか広まっていないように筆者には思われます。また、原書を読まれた方の中からも「本が分厚すぎて読みきれない・・・」という嘆きの声も聞かれます（DDD難民という言葉もあるそうです）。そこで本連載では、全3回に分けて、DDDの全貌を簡潔に紹介してみたいと思います。
DDDはタイトルからは一見分かりにくいのですが、いわゆるパターン本の1つです。しかし、DDDは全体が読み物の体裁で編まれているため、パターンカタログが読み物から独立しているもの（『デザインパターン』『J2EEパターン』『エンタープライズアプリケーションアーキテクチャパターン』など）に比べ、パターンの閲覧性は良くありません。本連載では、すでに一度読破された方にも有用な資料となるように、パターンカタログとしてDDDを再構成してみます。
ドメイン駆動設計（Domain-Driven Design）とは
まずは、DDDとは何か、から始めましょう。そもそも「ドメイン」とは、アプリケーションが対象とする業務領域のことです。本書では、ドメインを「知識、影響力、活動の一領域」と定義しています。業務アプリケーションでは、アプリケーションをプレゼンテーション層、ドメイン層、データソース層の3層に分けるアーキテクチャが主流ですが、このドメイン層がユーザの業務に直接的に関わる部分になるわけです。したがって、ドメイン層を正しく構築できるかどうかが、そのままアプリケーションの成否に影響します。
DDDは、オブジェクト指向コミュニティの間で長年培われてきたドメインモデリングのノウハウやベストプラクティスを集大成した、1つの設計思想／哲学です。ドメインモデルをこれから構築しようとする人に、設計上の判断を下すための枠組みと、ドメイン設計について議論するためのボキャブラリを提供するものです。TDD（Test-Driven Development、テスト駆動開発）やFDD（Feature-Driven Development、ユーザ機能駆動開発）と一見名前は似ていますが、DDDはなにか新しい開発プロセスを提唱するものではないことに注意してください。ただし、DDDは基本的にアジャイルな開発プロセスを前提にしています。
ドメインモデルを中心にすえた設計思想
DDDとはどんな設計思想かを簡潔に説明すると、ドメインモデルをソフトウェア開発の中心にすえ、コードやコミュニケーションを常にドメインモデルと一体化させながら、ドメインモデルを反復的に深化させることでより価値の高いアプリケーションを生み出していこうとする考え方です。ドメインモデルをすべての中心に置くので、「ドメイン駆動」というわけです。
DDDの要点は、次の3点にまとめられます。
- ドメインモデルは、ドメイン知識を深めながら反復的（iterative）に深化させていく
- ドメインモデルが、開発者とドメイン知識をもつ人（ユーザ、専門家等）との間の共通言語となるようにする
- ドメインモデルと実装コードとがきちんと対応付けられるようにする
DDDでは、1回きりの開発で完璧なドメインモデルを設計できるとは考えません。優れたモデルは、何度かアプリケーションのリリースを繰り返す中でようやく得られるものと考えます。こうしたドメインモデル探究の過程では、当然ドメイン知識をもった専門家との対話が不可欠です。開発者と専門家の間で誤解のないコミュニケーションを行なうには、ドメインモデルを専門家が理解できる言葉で構築する必要があります。さらに、ドメインモデルの深化がアプリケーションに正しく反映されるには、実装コードがドメインモデルと対応付けられていなければなりません。逆に、モデルを実装していく過程で、新たなドメイン知識を発見することもあるでしょう。ドメインモデルと実装コードには、双方向の関連付けが必要となります。
DDDはパターン本の1つ
DDDは、上記のノウハウをパターンの形式で体系化しています。書籍タイトルに「〜 Patterns」「Patterns of 〜」などと入っていないため気付きにくいのですが、DDDはれっきとしたパターン本の1つです。
DDDパターンは、Alexander形式を採用しています。Alexander形式とは、パターン言語の生みの親である建築家のChristopher Alexander氏が、建築のパターンを記述するのに用いた形式です。最初に写真やイラストなどの「イメージ」が掲載され、「文脈」「問題の記述」、間に「Therefore（ゆえに）」という言葉を挟んで「解決法の記述」「結果／実装上の考慮／例」、最後に「次の文脈」という構造になっています。しかし、有名なGoFのデザインパターンとは違い各項目がはっきりと節に分かれておらず、パターンのことを意識せずにそのまま読み物として読めるのが特徴です。
DDDに収録されているパターンは、全部で40あります。アンチパターンも含めると、41パターンになります。
本書は4部構成になっており、したがってDDDパターンも4つの分類に分かれます。
- Putting the Domain Model to Work （ドメインモデルを動かす）
- Building Blocks of a Model-Driven Design （モデル駆動設計の基本要素）
- Refactoring Toward Deeper Insight （さらなる洞察へ向けたリファクタリング）
- Strategic Design （戦略的デザイン）
第I部のパターンは、DDDの目標を示したものです。第II部では、ドメインモデリングの基礎的なベストプラクティスをパターンにまとめています。第III部は、ドメインモデルをさらに深めていくためのより実践的なパターンを説明します。最後の第IV部では、1アプリケーションの範囲を超えて、他のシステムとの連携が必要なアプリケーションや、複数のドメインが関係する大きなプロジェクトでDDDを実践するためのパターンが示されます。
SOAにも通ずる設計思想
DDDが単一アプリケーション内のドメインモデルの作り方についてだけ語っているものだと考えてしまうのは、DDDの一面だけしか理解しないことになります。本書の大きな部分を占める第IV部「Strategic Design」は、1アプリケーションのレベルを超えて、経営戦略的（strategic）な視点を必要とするシステム開発の舞台でDDDを実践する方法を提示しているからです。
SOAはいま、バズワードと言えるほどに注目を集めています。JBI（Java Business Integration）、SCA（Service Component Architecture）といったSOAの技術標準はすでに出揃っていて、標準に準拠したESB／BPM製品も充実しています。しかし、SOAを本当に成功させるには、単にそうした技術に習熟するだけではダメで、SOAを正しく構築する開発方法論が必要になるはずです。残念ながら、市場における技術標準やツールの充実とは対照的に、私たちが利用できるSOA開発方法論はまだまだ成熟していないのが現状です。
DDDが教える「戦略的デザイン」はSOAに特化したものではありませんが、私たちがいま必要としているSOAの方法論に大いに示唆を与えてくれる内容になっています。
アナリシスパターンとの違い
最後に、ドメインを扱うもう1つのパターンである『アナリシスパターン』（Martin Fowler著）との関係についても触れておきましょう。
アナリシスパターンとは、分析（analysis）のパターンです。デザインパターンがオブジェクト指向設計の中で繰り返し現れる構造をパターン化したものであるように、アナリシスパターンはドメイン分析の中で繰り返し現れる構造をパターン化したものです。「量」「勘定」「計画」「ポートフォリオ」「先物取引」など、再利用可能なドメインモデルがパターンとしてまとめられています。
アナリシスパターンとDDDの違いは、アナリシスパターンが「ドメインモデル」のパターンであるのに対し、DDDは「ドメインモデリング」のパターンであるということです。アナリシスパターンはドメインモデルの具体例を提供するものであり、DDDはどうやってドメインモデルを構築すればよいかを教えてくれるものです。
DDDにとっては、アナリシスパターンのモデルはドメインモデル探究の最初の出発点として利用したり、すでに構築されたドメインモデルを改良するためのヒントとして利用したりできるものです。DDDの第11章「Applying Analysis Patterns」では、実際に「在庫管理と会計」に関するいくつかのアナリシスパターンを使って、ドメインモデルを洗練させていく過程が説明されています。
DDDパターンカタログ
前置きが長くなってしまいましたが、ここから肝心のパターンカタログに移ります。DDDに収録されたパターンを1つ1つ紹介していきましょう。今回は、第I部「Putting the Domain Model to Work」にあるパターンを取り上げます。
I. Putting the Domain Model to Work（ドメインモデルを動かす）
第I部では、DDDが目指すべき最終的な目標を明確にします。ドメインモデルが有機的に機能し、開発プロジェクトを駆動するエンジンになるとはどういうことなのかを、パターンによって示します。登場する3つのパターン「ユビキタス言語」「モデル駆動設計」「実践的モデラー」は、DDDの基本3ヶ条とでもいうべきものです。
● Ubiquitous Language（ユビキタス言語）パターン
ドメインを正しく捉えた柔軟で価値の高いソフトウェアを設計するには、チームの共通言語を創造しなければならない。共通言語はユーザ、ドメインの専門家から、設計者、プログラマまで、分析／設計モデルからプログラムコードに至るまで、プロジェクトのすべての関係者、成果物に行き渡っていて、同じ意味で理解されるようなユビキタス（遍在的）な言語である。ドメインモデルがユビキタス言語となるようにし、ドメインモデルを介してプロジェクトが一体となるようにする。
● Model-Driven Design（モデル駆動設計）パターン
ユビキタス言語を実現するには、プログラムコードにおいてもドメインモデルが正確に表現されていなければならない。ドメインモデルとプログラムコードとが常にお互いを反映するように保つことで、ドメインモデルの変更がそのままコードの修正を促し、逆にコーディングの中で得られた新たなドメイン知識が即座にドメインモデルに反映されるようになる。このようにモデルとコードを緊密に結びつけるのがモデル駆動設計（MDD）である。MDDを実践するには、開発ツールやオブジェクト指向プログラミング（OOP）のようなプログラミングパラダイムが必要になる。
● Hands-On Modeler（実践的モデラー）パターン
もしモデラーがプログラムを書けなかったり、プログラマがドメインモデルに興味を示さなかったら、MDDの利点であるモデリングとプログラミングの好循環は生まれない。また、チームのコミュニケーションもそこで停滞してしまう。MDDを通してユビキタス言語を実現するには、モデラーが動くプログラムを書けなければいけないし、同時にプログラマがドメインモデルを理解し、修正できなければならない。つまり、チームのすべての開発者は、プログラムを書くモデラーでなければならない。
[補足] DDDとMDD、DDDとオブジェクト指向
DDDとMDDは一見よく似た概念で、DDDの中でそれぞれがどのように位置付けられているのか分かりにくいところがあります。両者の違いについては、著者Eric Evansが「Domain-Driven / Model-Driven」という記事で説明しています。
内容を簡単に解説すると、DDDとは「ドメイン」を最も重視し、それをすべての中心に置く方法です。MDDは「モデル」を元に行なう設計技法を指します。ドメインの複雑さを理解し、ソフトウェアに反映させる最も良い方法はモデルを使うことである（とDDDは仮定する）ために、DDDはその実現方法の中心にMDDを採用します。一方で、MDDは必ずしもドメインだけが適用範囲ではありません。UIやアプリケーションフレームワークなど、純粋に技術的なものにも適用できます。MDDはDDDにとって必須ではないが、ごく自然な伴侶という関係になります。
もう1つ、DDDとオブジェクト指向（OO）との関係についても触れておきます。「ドメインモデリング ＝ OO」と思いがちですが、DDD自体は必ずしもOOを前提としたものではありません。ただ現実的には、MDDを実現できる最良のプログラミングパラダイムがOOPであるために、OOが積極的に使われているということです。関数型プログラミングでMDDが実現できるのであれば、それでも構わないわけです（関数型が有効なドメインは限られているとは思いますが・・・）。
同様に、DDDではモデリングの記法にUMLを使うことも必須ではありません。DDDでは、UMLに囚われることなく、ドメインをより良く理解できる記法があれば、それを積極的に採用することを推奨しています。
次回
次回は、本書の第II部「Building Blocks of a Model-Driven Design」と第III部「Refactoring Toward Deeper Insight」から、16のパターンを紹介します。この16パターンが、DDDの中心を構成する部分です。ドメインモデリングのノウハウと設計指針とが、次回から本格的に展開されていきます。お楽しみに。
|
| © 2007 OGIS-RI Co., Ltd. |
|
