Brace, Paren, Semicolon.

受験勉強中

エリック・エヴァンスのドメイン駆動設計を読み始めたけど、分からないことが多い

f:id:oimou:20160812011400j:plain

最近、エリック・エヴァンスドメイン駆動設計(通称:DDD本)を読んでいます。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

ネット上で見かける「分厚い」とか「わかりにくい」という意見に圧倒されて、なんとなく食わず嫌いしていたDDD本ですが、ようやく手を付けました。まだ読み終わってはいませんが、考えをまとめるために感想など書いていきたいと思います。

本を読み始める前の知識レベルと立場

ドメイン駆動設計(以後、DDD)」というのは、察するに、きっとドメイン駆動でソフトウェア設計を行うことを指すんでしょう。 ドメイン駆動というのは、つまりソフトウェアが問題解決せんとする対象領域(=ドメイン)の考え方に則って(=駆動)設計を進めるということなんでしょう。

そのくらいの知識レベルで読み始めました。

なお、自分の立場はどちらかというと「開発者」寄りです。

第1部 ドメインモデルを機能させる

ドメインをいかに切り取って設計に落とすかが、ここでのキモになります。

どんなモデルも、現実の何らかの側面や興味の対象となる概念を表している。モデルとは簡素化である。つまり、当面の問題を解決する上で関連する側面を抽象化し、それ以外の詳細を無視することによって行われた、現実に対する1つの解釈なのだ。

ドメインを理解し、ドメインモデルを作り上げ、それをチームメンバでのコミュニケーション基盤とするというのは、通常のソフトウェア開発プロジェクトでも行われていることだと思います。 DDDでは、ドメインモデルの基本的用法を次の通り定めています。

モデルの基本的用法

  1. モデルと設計の核心が相互に形成しあう
  2. モデルは、チームメンバ全員が仕様する言語の基盤である
  3. モデルとは、蒸留された知識である

2はストンと理解できますね。本書では「ユビキタス言語」という用語も登場します。

1はDDDについて話を聞くたびによく耳にする特徴でした。つまり、コードの中でモデルと同じ語彙を使ったり、逆にコードの変更がモデルにフィードバックされたり、といった深い関連が基本的用法として定義されているのです。 これほどモデルと実装が密結合した設計は、相当プログラミングに明るくないとできないんじゃないかと不安になってしまいますが、実際どうなんでしょうね。

3は2と似ているような気もしますが、ドメインを観察し、理解し、切り取って抽出するという蒸留プロセスを経て得られた知識のことを指しています。 こうして得られた知識は、チームがドメインの捉え方の可視化になります。

うーん、でもやっぱり2と3は似ているように感じます。ドメインの捉え方が可視化されたら、それはすなわち言語基盤なのではないか?と思ってしまいます。分かれている理由がまだよくわからない。

第1章 知識をかみ砕く

筆者自身のプリント基板デザインツールの設計についての事例が紹介されています。ドメインエキスパートと開発者が一緒になってモデリングを進めています。

PBCエキスパート1:コンポーネントはチップでなくてもよいのです。 
開発者:では、単に「コンポーネント」と呼んだほうがよいですか?
エキスパート1:我々は「コンポーネントインスタンス」と呼んでいます。同じコンポーネントが多数ある場合もありますから。

ところでこの事例では、ドメインエキスパートと開発者の両者がモデリングについて非常に前向きに議論しているように見受けられます。おそらく、この例ではドメインエキスパート側もプリント基板デザインをしているだけあって、モデリングに向き合うハードルが元々低いんではないでしょうか?

ドメインエキスパートによってはモデリングに向き合うハードルに差があるはずです。それをどうやって乗り越えてもらうか、うまく二人三脚でモデリングに取り組むか、もう少し実践的な話も知りたくなりました。

第2章 コミュニケーションと言語の使い方

ユビキタス言語」と呼ばれるようなチーム共通語彙は非常に大切ですが、残念ながらあまり一般的ではありません。ドメインエキスパートは専門用語を(時にさまざまなニュアンスで)使用し、開発者もまた独自に抽象化したモデルの専門用語を使用します。この通訳コストが非常に高い。高いだけならまだしも、その弊害は「言った言わない問題」「実装漏れ」などの形で現れてくるからまた厄介なんでしょうね。

ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に異議を唱えるべきであり、開発者は、設計を妨害することになるあいまいさや不整合に目を光らせるべきである。

開発者としてのべき論はよく分かります。一方で、ドメインエキスパートに対して異議を唱えてもらうのは具体的にどうすれば良いのでしょうか?まさか「異議を唱えてください」と伝えるだけで達成できるようなことでもない気がするので、もう少し実践的な例が知りたいです。これも後で調べてみよう。

また、この章では「モデルは図ではない」という重要な記述もあります。一通り読み終わったらまとめることにします。

第3章 モデルと実装を結びつける

そのプロジェクトには、ドメインモデルがあった。しかし、動作するソフトウェアの開発を直接支援しないなら、紙に書かれたモデルが何の役に立つというのだろう?

確かに。DDDに際して「ドメイン」「モデル」「コード」という3要素があるとして、その結合度にはいくつかパターンがありそうだと気づきました。

  1. ドメイン」<-(密)->「モデル」<-(疎)->「コード」
  2. ドメイン」<-(疎)->「モデル」<-(密)->「コード」
  3. ドメイン」<-(密)->「モデル」<-(密)->「コード」

1は、あまりにも写実的にドメインモデルを作りすぎてコードに落とせなくなってしまったパターン。
2は、俗にいう「誰が書いても同じコードになる設計書」問題と似たようなパターン。
3は、DDDが理想とするドメインモデルの姿ですね。

でも、そうだとすると気になるのが、そんなに密結合なドメインモデルをどうやって作成・更新していけば良いのか?という現実的な問題です。その答えのひとつがこれでした。

実装を一分の狂いもなくモデルに結びつけるには、通常、オブジェクト指向プログラミングのようなモデリングパラダイムをサポートする、ソフトウェア開発のためのツールと言語が必要である。

…なるほど、だからよくJavaでサンプルコードが紹介されていたりするんですね。しかしツールの支援が必要にせよ、コードが常にモデルに反映される開発環境というのは理想的のように感じます(実際どうなのかはよく分からない)。

まとめ(られない)

まだ第1部をサラッと読んだだけですから、まだまだ分からないことが多いです。特に、実践的な例を考えながら読んでいるとやはり色々ハードルがあるように思えてきます。引き続き読み込んでいきましょう!