fortunecodec

DDD（Domain Driven Design）で有名なEric Evansが、QCon2008（でも公開されたのは昨日なんだけどなぁ）にてインタビューを受けた模様が公開されているので、見てみました。

InfoQ: Eric Evans on the State of DDD （infoQ）

Ericさんはとても穏やかな語り口の方で、慎重に言葉を選びながら丁寧に回答されています。特に印象に残っている点をメモしておきます。

• ユーザビリティの向上とDDD
  • よくUIとドメインを全く分離して検討されているが、それには反対
  • UIは対象のアプリケーションが何をしてくれるのかというコンセプトを明確にしてくれる
  • ユーザビリティはコンセプトの明確さから得られるもので、「ボタンは右端に置く」とか小手先の話ではない
  • Ubiquitous Languageの考え方に基づき、関係者がコンセプトを明確に共有しなければ優れたユーザビリティは実現できない
  • したがって、少なくとも最初は、両者を一緒に検討するべきだ

当然、アプリケーションアーキテクチャとして両者を混在させることを推奨しているわけではなくて、アプリケーションのコンセプトを明確にして、開発者やドメインエキスパートがそれを理解・共有するという位置づけでも、UI設計を積極的に活用するべきだということでしょう。

関係者のコミュニケーション（インタラクション）を増やして要求を引き出すという観点では、ペーパープロトタイピングが具体的な技法のひとつとして思い浮かびます。まぁWebアプリならHTML紙芝居でイメージ共有することも多いと思いますが、それだとコンセプトのような深いレベルよりも、「ボタンを右端に置く」話になりがちですね。

• DSL（Domain Specific Language）はUbiquitous Languageなのか？
  • 違うと思う
  • Ubiquitous Languageは関係者間の会話で使われることが想定されるもの
  • とはいえ、Ubiquitous Languageが表すものをダイレクトにコードできると嬉しいよね
    • Javaなんかで上手く設計してれば、上手くできたりもするし
  • 最終目標は、Ubiquitous Languageとプログラミング言語が限りなく同一になること
  • DSLは多様な方向性を持っているが、それ専門の重量級のものから軽量級のものがある
  • Ubiquitous Languageパターンで想定していたのは、既存の言語で注意深くコーディングした結果、DSLのようになるような軽量級のもの
    • もし軽量級の立場でコーディングしていたら、多分殆どUbiquitous Languageパターンを実践していると言っていい
  • DSLはまだまだ発展途上の領域だから、はっきりしたことは言えないけど

DSLの話になると、昔の職場でPaul Graham信者に洗脳されたせいか「Lispでいいんじゃーないのー」とか浮かんでしまうのですが（私は書けませんけど）、このあたりはオブジェクト指向分析/設計（OOA/D）のメリットに通じる話ですよね。

OOAで対象ドメイン要素の意味や構造を分析者の立ち位置から単純化して理解・共有可能にして、そこから同じ言葉や構造を使ってOODへシームレスに繋げられるっていうのがOOA/Dの大きなメリットだ、というやつです。OOP（オブジェクト指向言語）を使って実装すれば、OODからダイレクトにソースコードまで繋がる…というのが更なる理想象です。実際、上手く設計されたクラス構造は、分析結果を理解している関係者からすればとても理解し易く、保守も簡単になるものです。

Ubiquitous Languageは人間用で、DSLは実装用ということですが、両者（の多く）はやはりOOの理念の申し子でもあるわけで、OOの目指すゴールへどのようにアプローチするか、という話なんでしょう。

• DDDを導入するための効果的なステップは？
  • パイロットプロジェクトを立ち上げて、そこで使ってみる
  • その際、まず何よりもコンテクストを明確に整理して臨むことが大事
    • レガシーと新規がごちゃごちゃだったり、関係者が入り組んでたりしたらダメ、絶対
    • 本の14章にあるContext Mapを使ってコンテクストを整理して、取り組む領域を特定すること
  • そのプロジェクトには、優秀な要員を組み入れること
  • 更に、そのプロジェクトは簡単すぎず、ビジネス的な価値がちゃんとある開発対象を選ぶこと

DDDは、その本のサブタイトルが「Tackling Complexity in the Heart of Software」というだけあって、ソフトウェアが備える本質的な複雑さに対処するためのアプローチであって、簡単なCRUDアプリだとあまり嬉しくないでしょうね。

このあたり、OOA/Dとか具体的な要素技術（フレームワークなど）の導入にも同じようなことが言えます。難しい問題に立ち向かうための技術なのに、妙にシンプルなシステムに適用して「却って複雑になっちゃったー」みたいな結果に終わるっていうのはありがちです。

メモした他にも、テスト用フレームワーク（FitとかFitness）を引き合いに出してテストについて語ったり、要素技術への懐疑的な態度、言語を組み合わせた開発に関する議論などにも話題が及んだりしています。興味のある方は、是非見てみてください（英語なので大変ですが…←大変だった）。