ここに掲載したインタビュー記事は、無料のダウンロード書籍『Domain-Driven Design Quickly』(source)(InfoQ発行)からの抜粋(6章)です。このインタビューの中で、Eric Evans氏はDDDをシステム開発の現状に当てはめ、今、DDD(Domain-Driven Design、ドメイン駆動設計)が重要とされる理由について説明しています。
InfoQ: 今日、DDDが依然として重要とされる理由は何でしょうか。
Eric Evans氏(以下、EE): 基本的に、DDDは、ユーザーが関わっているドメインの根本的な問題に重点を置くための理念であり、最も重要なことはドメインについて理解し、そのドメインのエキスパートと協力してドメインを概念的な形にし、それを使用して強力かつ柔軟なソフトウェアを構築することです。
これは、時代遅れの考え方ではなく、複合的かつ複雑なドメインにおいては必ず当てはまるものです。
長期的な傾向としては、ビジネスの深層部でより一層複雑化する問題に対してソフトウェアを適用する方向にあります。この傾向は、Webの台頭によりここ2、3年は停滞していたように思います。つまり、簡単な操作によるWeb上でのデータ処理が非常に重要視され、豊富なロジックや複雑なソリューションは注目されませんでした。Web対応には多くの労力が必要で、Web上では単純な処理を行うことも当初は簡単ではなかったため、開発努力のすべてはこの作業に注がれることとなりました。.
現在は、基礎水準でのWeb利用が広く浸透し、プロジェクトにおいては、ビジネスロジックに対する要望が再び大きくなりつつあります。
ここ最近では、Web開発用のプラットフォームが成熟してWeb開発の生産力がDDDに十分見合うようになり、また、好ましい傾向も多く見られるようになりました。たとえば、SOAの場合、適切に活用することでドメインを分割するための非常に有効な手段となります。
一方で、アジャイルプロセスの影響により、ほとんどのプロジェクトでは、現在、イタレーションの実施やビジネス関係者との綿密な連携、継続的インテグレーションの適用、および活発なコミュニケーション環境での作業が、当然あるべきものとして想定されています。
したがって、当面の間、DDDの重要性はさらに高まり、その基盤が形成されていくと思われます。
InfoQ: テクノロジープラットフォーム(Java、.NET、Rubyなど)は今も進化し続けていますが、DDDはこれらのプラットフォームにどのように応用できますか。
EE: 実際には、新しいテクノロジーやプロセスについては、チームがドメインを中心に据えて作業を進める上で、それらが障害となるかどうかではなく、促進剤となるかどうかで判断することが必要です。DDDはテクノロジープラットフォームに特化したものではありませんが、プラットフォームの中には、ビジネスロジックを構築する際の表現方法がより多彩なものや、障害となるクラッタが他のプラットフォームより少ないものがあります。後者については、特にひどかった1990年代の終わり頃以降、ここ2、3年は好ましい傾向が示されています。
ここ2、3年で既定の選択肢となったJavaは、オブジェクト指向言語特有の表現技術を備えたプログラミング言語です。障害となるクラッタについても、Javaの基本言語はそう悪くはありません。Javaにはガーベジコレクションがあり、実際にはこれが必須の機能となっています(C++では対照的に、下位の詳細に対して非常に多くの配慮が必要でした)。Javaの構文にはクラッタが含まれていますが、POJO(Plain Old Java Object、通常の従来型Javaオブジェクト)は比較的理解しやすく、Java 5の構文革新によりさらに読みやすいものとなっています。
最初にJ2EEフレームワークが登場した当時は、このような基本的な表現技術は、大量のフレームワークコードの中に完全に埋没していました。EJBホームや、getやsetというプリフィックス付きのあらゆる変数向けのアクセサーなど、初期の慣例により、品質の悪いオブジェクトが構築されていました。ツールの操作は非常に困難で、開発チームはそれらを機能させるためだけにすべての労力を費やしていました。オブジェクトの変更は非常に難しく、そのため、生成されたコードやXMLで大きな問題が発生しても、それを大幅に修正することはあまりありませんでした。そして、このようなプラットフォームにおいては、効果的なドメインモデリングを行うことはほぼ不可能でした。
これらのプラットフォームに命令機能を組み込み、非常に原始的な第一世代のツールを使用して、httpおよびhtmlを介した(目的に合致しない)ウェブUIを構築します。この時期、まともなUIを作成しメンテナンスすることは非常に難しく、したがって、内部の複雑な機能設計については、ほとんど注目されることはありませんでした。皮肉なことに、オブジェクト技術が主流となったまさにそのとき、高度なモデリングと設計が大打撃を受けることになったのです。
.Netプラットフォームにおいても、処理する問題によって程度の差異はありますが、その状況は類似しています。
低迷期はありましたが、傾向はここ4年間ほどで変わりつつあります。まず、Javaについてみると、フレームワークの選択的使用方法に関する高度な新技術がコミュニティに集まり、またさまざまな新しいフレームワーク(そのほとんどはオープンソース)が徐々に改善されつつあります。HibernateやSpringなどのフレームワークは、J2EEが取り扱っている特定のジョブを、より簡単な方法で処理します。UIの問題を処理するAJAXなどのアプローチでは、労力が軽減されます。この結果、現在のプロジェクトにおいて、J2EE要素の選択はより洗練されたものとなり、価値を付加してこれらの新しい要素に適合させることが可能になっています。POJOという言葉は、このような時代に登場しました。
成果は段階的ですが、プロジェクトの技術的努力については減少傾向が顕著になっています。POJOに関しては、ビジネスロジックの他のシステムからの分離技術が明らかに改善しています。これにより、ドメイン駆動型設計が自動形成される代わりに、現実的な好機を実現しています。
以上がJava環境の現状です。次に、Rubyという新しく登場した言語について見てみましょう。Rubyの構文は表現機能が非常に高く、この言語の基礎水準はDDDにとって最適です(ただし、この種のアプリケーションに関する実際の使用についてはまだあまり聞いたことはありません)。Railsでは、遂に、1990年代前半のWeb以前のUI作成技術と同じような簡単なウェブUIの作成を実現しているということなので、私は非常に期待をもっています。現在、この機能は主に、膨大な数の、背後のドメインがあまり重厚でないWebアプリケーションを構築する際に利用されています。これらのWebアプリケーションも、かつては、非常に構築が困難でした。しかし、私は、UI導入部分に関する問題が減少し、これによってドメインへの注目度がより高まることを期待しています。Rubyの使用によってこの方向に進んでいけば、(おそらく、若干のインフラストラクチャ部品による補強は必要ですが)DDDを実現する理想的なプラットフォームも提供されるようになると考えています。
最先端の技術といえば、ドメイン固有言語(DSL)の分野における努力もすばらしいものがあります。これは、私がDDD実装に向けた大きな次のステップとして長い間考えてきたものです。現在に至るまで、私達の必要としているものを実際に得られるようなツールは登場していません。しかし、この分野での試みはこれまで以上に活発に行われており、私自身は期待をもっています。
現時点で私が言えることは、DDDの活用に取り組んでいる多くの人々がJavaあるいは.NET、また一部ではSmalltalkを使用しているということです。これは、即効性のあるJava環境においては好ましい傾向といえます。
InfoQ: あなたが書籍を執筆されて以降、DDDコミュニティはどのように変わりましたか。
EE: 1つうれしいことは、私が書籍の中で紹介している理念を人々が理解し、私が予想していなかった方法でこれらを使用していることです。これはたとえば、ノルウェーの国営石油会社StatOil社における戦略的デザインの活用などです。これについては業務に関わったアーキテクトが見聞レポートを掲載されています http://domaindrivendesign.org/articles/(英語)参照)。
特に、コンテキストマップを使用して既製のソフトウェアの構築や購入を決定する際の評価を行っている例もあります。
これとはまったく異なる例として、多くのプロジェクトで必要となる基本のドメインオブジェクトのJavaコードライブラリを開発することによって、問題を調査したケースもありました。これについては、http://timeandmoney.domainlanguage.com(英語)をご覧ください。
たとえば、Javaオブジェクトを実装しつつ、熟練したドメイン固有言語の概念をどこまで推し進めることができるか、といった内容に関する調査の実施などがあります。
このように、DDDの理念は非常に多くのケースで応用されており、私は、人々から実際の体験を聞けることをいつもうれしく思っています。
InfoQ: これからDDDを学ぼうとしている人たちに何かアドバイスはありますか。
EE: 私が書いた本を読んでください。そして、timeandmoneyコードライブラリをプロジェクトでぜひ活用してください。私達の本来の目的のひとつは、その使用を通じて知識を得られるような、適切な例を提供することです。
1点注意していただきたいのは、DDDは主にチーム作業を対象としており、場合によっては、誰かが伝道者としての役割を担う必要があるということです。実際に、この実現に向けて努力しているプロジェクトを探してみてください。
ドメインモデリングでは、いくつか留意すべき事項があります。
- 実際にプロジェクトに参加してください。モデラーはコーディングを行う必要があります。
- 具体的なシナリオ作りに重点的に取り組んでください。抽象的な思考は具体的な事例として明確化してください。
- DDDをすべてに応用するのはやめてください。コンテキストマップを作成してDDDを適用する部分とそうでない部分を決定してください。これにより、適用外の部分については懸念する必要がなくなります。
- 検証を多く行い、多くの失敗の発生を想定しておいてください。モデリング作業は創造的なプロセスです。
Eric Evans氏について
『Domain-Driven Design: Tackling Complexity in Software』 (Addison-Wesley出版、2004年)の著者。
1990年代前半以降、多くのプロジェクトでさまざまなアプローチ、さまざまな成果を対象とした大規模なビジネスシステムの開発に従事する。書籍では、これらの経験の集大成として、チームが、複雑なソフトウェアシステムとビジネスニーズとを一致させ、システムの規模が拡大してもプロジェクトをアジャイルな状態に維持するためのモデリングと設計技術の体系について説明している。
現在は、コンサルティンググループ"Domain Language"の代表として、ドメイン駆動設計に取り組むチームの指導、トレーニングを行い、開発生産性の向上とビジネスへの付加価値化を支援している。
原文はこちらです：http://www.infoq.com/articles/eric-evans-ddd-matters-today
（このArticleは2006年12月20日にリリースされました）