Floyd Marinescu です。Domain Driven Design の著者、Eric Evans とここスプリングエクスペリエンスに来ています。Eric、自分自身のことについて、そして最近の活動について少し教えてください。

最近は、コンサルタント業務を行ない、ドメイン駆動設計に関して、いろいろなお客様をサポートしています。具体的には戦略を考えたり、トレーニングを実施したりといった活動です。もちろん、スプリングエクスペリエンスのようなコンファレンスにも出席しています。

十分な知識がない人のために、ドメイン駆動設計について教えてください。

ドメイン駆動設計の重要なポイントは、まずはソフトウェアの対象となるビジネスやドメインについてもっと熟考し、そのあとでソフトウェアの開発に使用するテクノロジーやすべての手法、さらにはプロセスについて考える必要があるということです。 これが、ドメイン駆動の重要な部分です。しかし、実際にこれを実行することは、口で言うほどは簡単なことではありません。したがって、きわめて多くのことが導入されます。そして、もちろん、ドメインが複雑になると、ドメインのモデル化がドメイン管理の鍵となります。これが、ドメイン駆動設計とモデルの間に大きな関連性がある理由です。

チームでドメイン駆動設計を行なう場合、ドメイン駆動設計を有効に実施するためには、最低でもどのようなことが必要とされますか？

さまざまなパターンが考えられますが、ドメイン駆動設計の最も基本的なパターンは、おそらくユビキタス言語でしょう。 つまりこういうことです。ドメインの専門家、社内の専門家がドメインについて議論する際に基盤となる概念を練り上げるときに特定の言語を使い、そして、その言語には、概念の洗練さを反映して常に改良が加えられていきます。そして、チームのほかの開発担当者、設計担当者と議論する際に共通の言語を使います。これは、規格書で使われる言語と同じものであるため、概念モデルの改良に合わせて規格書も改良する必要があります。 きわめて重要なポイントは、この言語は、テクノロジーで実現できる範囲を拡大するコードで使用する言語と同じものです。それがユビキタス言語と対応するようにします。そういった理由でユビキタスと呼ばれます。プロセス全体で使われるからです。 しかし、そのためには、境界があるという認識、モデルは空間に浮かんでいるのではないという認識、そのモデル特定の状況において適用され、その状況には明確に定められた範囲、つまりそのモデルの限定的な状況があるという認識を持つ必要があります。これら 2 つの要素でドメイン駆動設計を行なう場合は、もっと具体的な問題の解決に役立つことがほかにも数多くあるでしょうね。

その 2 つの要素について、まずはユビキタス言語をどのような方法でコード化するのか、そしてそれは実際にどのような感じなのかについてもう少し詳しく教えてください。

採用している実装テクノロジーのタイプによって大きく変わります。 実際に、オブジェクト指向のプログラミングの利点は、特定の種類のモデル、概念システムと使用する傾向が高い言語、実際の実装を綿密に対応付けることができるという点です。 したがって、たとえば Java では、構文的には英語の文章と大きく異なるものの、意味的には近いコードを記述できます。したがって、慎重に作られたオブジェクト指向のシステムの JAVA のコードのその行を読んで、「意味は理解できる。英語の構文を使って、非常に似通った言葉で意味を説明できる」と言うことができます。 したがって、これがオブジェクト指向のプログラミングの利点の 1 つですが、限界はあります。主語と動詞を言い当てることはできますが、ほかにも言いたいことはあるかもしれません。これが、ドメイン固有言語やその他のさまざまな手法など、ほかのテクノロジーが探し求められている理由の 1 つです。しかし、それが現状なのでしょう。

範囲が限定された状況について詳しく教えてください。

範囲が限定された状況は基本の 1 つですが、一般的にはあまり考慮されない項目の 1 つでもあります。 モデルについては考えますが、このモデルに意味を与える状態や状況については考えません。このホテルのこの場所に座っているときに、私が「ホームに帰りたい」と言えば、それはおそらく空港に行き、飛行機に乗り込み、カリフォルニアに帰りたいという意味になるでしょう。球場のグラウンドで、「ホームに帰りたい」と言えば、ベースを回って得点をあげたいという意味になるでしょう。 ソフトウェアを記述したり設計したりするときに、こういうことはあまり考えません。簡単な英語の文章の意味、そしてもちろん設計中のドメインオブジェクトの意味は、非常に状況に依存しています。 したがって、範囲が限定された状況とは、それを明示的に認識することであり、「この状況においてこのモデルを使っている」と言うことです。サブシステムによってそれを明確にできるかもしれません。「このサブシステムにおいては、これが状況である。つまり、私たちが使っているのはこのモデルであるという意味である」とも言えます。 または、「このチームが行なっている作業内で、このモデルが適用されている」とも言えます。それは一般的にチームの範囲と一致します。これらも概念モデルであり、ほかの人と自動的に共有できないため、十分密接な関係を築いて本当に打ち解けている必要があるからです。 これが、範囲が限定された状況の本質であり、大規模なプロジェクトにおいては、常に複数のモデルが有効であるため、範囲は重要であり、そうでなければ、いろいろなことがごちゃ混ぜになり、さっぱりわけがわからないことになります。

ユビキタスな言語と範囲が限定された状況はどのような方法で文書化し、この情報をチーム内でどのような方法で共有するのですか？

いい質問ですね。通常は、このようなことは問題にはならないのですが、私は問題であると考えています。 ユビキタス言語に関して言えば、実施されている傾向は高いと言えます。場合によっては、用語集などを作成していることもありますが、それには注意しなければなりません。用語集は言語を凍結させますし、進化することが言語の価値の1つだからです。範囲が限定された状況については、実際にはユビキタス言語そのものよりもはるかに安定しているのですが、組織内、さらには部門ごとの境界に設置されたチームにさまざまなコードが存在すれば、範囲が限定された状況はかなり安定したものになります。 実際に私は、本で使用したような非公式な表記方法を使って図式化しています。特別な表記方法は定めてはいませんが、実際に図を描いたり、通常は設計担当者やプロジェクト責任者といった人たちを集めたりすることには価値があると言っているわけです。また、重要なお客様数人を集めて、状況マップがどのようなものになるのかを導き出し、チームの全メンバー、誰とでも共有することも可能です。これは十分に行なう価値があることであり、実際に私自身がお客様に対して頻繁に行なっていることです。

ドメイン駆動設計が多用されていることに対してどう思いますか？また、ドメイン駆動設計を多用していることは、どのようにしたらわかりますか？

このことについては、ずっと気になっていたので、最近よく話題にしています。モデル信望者が最初に犯す基本的なミスとしてますます目に付くようになったのは、すべてのものをモデル化すべきであるという考え方、システム全体をモデル化しオブジェクト指向化すべきであるといった考え方です。 最近になってわかってきたことなのですが、このような考え方によって、取り組みが希薄化され、モデル化の責任に対する気力がなくってしまいます。そして、実際に両方のシステムはおそらく 90% CRUD（create、read、update、delete）され、そのような問題に対する簡単な解決策が存在します。 したがって、私が本当に注目してきたことは、ドメインの難しくて複雑な部分において、ゼロ化することです。この複雑な部分が本当に問題の原因になっています。モデル化の取り組みに焦点を当て、範囲が限定された状況という考え方を利用することによって、ほかの部分から分離し、いくつかの価値の高い困難な問題の範囲内において、モデル化によって実現できることが本当に見えてきます。困難なプロセスであるため、さまざまな価値が得られます。楽しみだけのためにやりたいと思うことではないし、データを収集しデータベースに入力するための莫大な数の画面を作成するためにやるべきことでもありません。ビジネス的な価値が得られる部分を求めて行なうべきです。

モデル化と言ったとき、実際には UML のモデル化を指していますか？それとも、クラスを記述することを指していますか？

モデル化という言葉は UML の図式化とほぼ同意語になりました。またソフトウェエアの層を意味していると考えることもできるでしょう。 しかし、私にとっては、モデル化というのはそれ以上にもっと基本的なことです。モデルは、概念的なシステムであり、一部の特定の問題または複数の問題に適用できる抽出の集合です。ソフトウェアが出現するずっと前にモデルはすでに存在しましたよね。そして、物理学の理論はモデルであり、地図は世界をモデル化したものです。ナビゲーションの地図、人口統計用の地図など、地図は特定の用途で使われています。そして、同じ理由で、自分のドメインのモデルを作成しますが、このモデルは、非常に蒸留度が高く、きわめて厳格であるだけでなく、特定の重要な情報を解明したり、特定の何らかの問題に取り組んだりする上で便利なドメインの概念を個別に選択したものでもあります。 あいまいに聞こえるかもしれませんが、それが本当にモデルというものです。つまり、辞書をひけば、抽出のシステムのように定義されているかもしれませんが、モデルの能力の一部は、その基本的な定義に戻ってくるのです。

つまり、UML のことを言っているのではないということですか？

UML は、一部のモデルの特定の特性を伝えたり記録したりするにはよい方法です。したがって、私たちはたいていオブジェクト指向のパラダイムで運営しているので、選ぶモデルの種類は次にようになります。「このような一連の事象があり、このような一連のオブジェクトがあり、それらがこのようにお互いに関連しています。 そして、これらはこのように連係していて、UML には表記法があり、それによって図示することができます。特に、オブジェクトの静的な関係という観点では。UML はすばらしいコミュニケーションツールです。そのような目的で使うのであれば、本当の資産になります。 そして、モデルのほかの側面のいくつかにおいては、実際にはじゃまになります。たとえば、ユビキタス言語とコードの結び付けについて話したときのように。また、ユビキタス言語全般は本来、もっとテキスト的なものです。したがって、実際には、旧式の単純な Java コードのほうが、もっと動的な何らかの関係を伝えようとする UML の図式化よりもわかりやすいと言えます。

ドメイン駆動設計は 2003 年に発表されたものですが、現在それに関する発言が大きくなってきているような気がします。今が、ドメイン駆動設計の時代であることの理由を教えてください。

私自身、このことに当惑してきました。最近大ブームになっていることに気づいたからです。 その理由の 1 つとして、本によって人々の意識がいくぶんか高まったということが挙げられます。このような考え方を表現する新しい方法を吸収する時期が必要だったのです。そして、そのような人たちが現在は自分自身で何らかのことを試してみる時間ができ、そして膨大な数の人たちが次のステップに移行していることに気づきました。したがって、このような静かさがあったのはそのためではないかと思います。 そして、それはさまざまな形態で現れました。たとえば、Jamie Nelson の『Applying Domain Driven Design and patterns（ドメイン駆動設計とパターンの適用）』などの新刊が発表されたこと、InfoQ がドメイン駆動設計の早わかりバージョンを発表したことなどが挙げられます。その手法を使う人たちもいます。興味深い体験レポートも書かれ始めました。 興味深いことがもう 1 つあります。これは、当然のなりゆきなのですが、ツールメーカーや技術者がそれを使って物事を行なおうとしていることであり、場合によっては、さまざまな方法があったり、ひどい結果を招いたりする場合もありますが、実際にテクノロジー基盤をドメイン駆動設計に若干適したものに変えている人もいると思います。 とにかく、実験が行なわれることにわくわくしています。私は、実験が大好きです。また、今後数年でどのような機能が実現するかがわかるでしょう。