『エリック・エバンスのドメイン駆動設計』読書メモー序文から第1章

『エリック・エバンスのドメイン駆動設計』の邦訳が出版され、1ヶ月近くたっている。

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

すこしずつ読み進めているのだが、本が分厚い上に内容も濃い。
そのため、読んでゆくうち忘れてゆかないよう、気になったところや要点だと感じたところメモしてゆく。

読了後に再読してメモを作成しているわけではないので、誤りを含むこともある。
こうした点は、指摘をいただければ修正するつもりで書く。

ちなみに、本格的な濃い議論をみたいのであれば、Twitter上で、#DDDjpのタグを追いかけることをおすすめする。

僕がドメイン駆動設計（以下、DDDという）へ期待することの１つは、分析と設計の橋渡しとして役割を果たしてくれることだ。

アジャイル開発の登場により、分断されてきた設計と開発は不可分であると認識され始めてきた。
設計→開発という一方向の流れではなく、開発→設計という流れも考慮したイテレーティブでフィードバックを重視した開発プロセスの確立、そして、そのプロセスを支えるプラクティス、技術の発達が、設計と開発を統合する流れをつくりつつある。

一方で、すなわちAsIsをいかにとらえるかという分析とToBeをどのように描き実現するかという設計をつなげる方法は、僕にとって明確ではない。
僕の知る限りでは、トム・デマルコの『構造化分析とシステム仕様』が分析した内容を設計に落としこむアイディアを提供してくれている。

構造化分析とシステム仕様<新装版>

DDDは、ドメインエキスパート、つまり、システム化対象の業務のプロとともに対象への知識を深める。
そして、プロセスなかで作成したモデルをプログラムに反映させることを主張している。
そのためのプラクティスも、『エリック・エバンスのドメイン設計』では紹介されている。

DDDは価値の高いシステムを開発するための、分析から開発まで知識を横串にカバーしている。
こうした点からは、僕が期待している以上の知を授けてくれそうだ。

モデルとはなにか

モデルとは簡素化である。つまり、当面の問題を解決する上で関連する側面を抽象化し、それ以外の詳細を無視することによって行われた、現実にたいする1つの解釈なのだ。(P.2)

現実をすっかりと写しとることを「モデル」と考えてはいけない。
モデルを作る人、観察者の興味や目的によって集中するべき点がことなり、関心がない部分は切り捨てられるものなのだ。
また、現実にたいする1つの解釈であることからモデルは複数、存在することもあるし、モデルを作る人、モデラがあたらな知識をえることによって書き換えられる可能性もある。

ドメインモデルとはなにか

ドメインモデルとは特定の図ではなく、図が伝えようとしている考え方である。(p.3)

図自体ではなく、モデルから読み取れる内容、ドメインエキスパートと開発者で共有された知識こそが、ドメインモデルだという意味だと思う。
図はあくまでもそのための材料、素材ということだろう。

そのため図だけに知識の共有を頼ってもいけない一方で、知識の共有を助けらえるよう、知識が洗練されてゆくごとに図も更新されてゆく必要がある。

ドメインモデルの3つの用法

1.モデルと設計の核心が相互に形成し合う。＜中略＞
2.モデルは、チームメンバ全員が使用する言語の基盤である。＜中略＞
3.モデルは、蒸留された知識である。(p.3)

従来のモデリングでは、概念、設計、実装、と用途によって使い分けるが、DDDで用途別のモデルを作成しない。
ドメインエキスパートとつくり上げたモデルをプログラムにまで反映させる。
モデルがプログラムにまで反映されることで、開発者の言葉とドメインエキスパートの言葉が一致する。
そのため、開発者とドメインエキスパートは、１つのモデルを共有しながら共同作業に取り組める。

ソフトウェアの核心

ソフトウェアの核心は、ドメインに関係した問題をユーザーのために解決する能力である。
それ以外の特徴はいずれも、どれほど重要だとしても、この基本的な目的を支えるにすぎない。(p.4)

開発者がドメインエキスパートとの協業を行わなければいけない第１の理由になるだろう。
価値の高いシステムをつくるために、ドメインにたいする理解、知識を深めることが不可欠だからだ。

効果的なモデリングの要素

1.モデルと実装を結びつける。＜中略＞
2.モデルに基づいて言語を洗練させる。＜中略＞
3.知識豊富なモデルを開発する。＜中略＞
4.モデルを蒸留する。＜中略＞
5.ブレインストーミングと実験を行う。(p.13)

開発者とドメインエキスパートが協業し続けられるよう、双方の努力が必要である。
モデルを実装に結びつけること、双方が使う言葉が共通の意味をもっていることはその基盤となる。
また、モデルを有効な状態にたもつために、不要な知識を削除したり、実装を通じたフィードバックによりモデルをつくりなおしたりという作業が不可欠なのだ。

知識を噛み砕く

知識のかみ砕きは独りで行う作業ではない。開発者とドメインエキスパートからなるチームが共同して行うもので、たいていは開発者が率いる。(p.14)

知識のかみ砕きは、システム化の対象となるドメインへの理解を深めることだ。
開発者の独力では、ドメインへの深く、正しい理解は達成できない。ドメインエキスパートの協力が必要だ。

一方で、ドメインエキスパートへの開発者の関与も不可欠だ。
ドメインエキスパートはシステム化のプロではないし、そのための方法論にも詳しくない場合がおおい。
システム化の手法やプロセスへドメインエキスパートが理解を深めることの手助けを開発者が行う。

開発者とドメインエキスパートは相互に学習しながら、ドメインへの知識を深め、ドメインモデルを構築してゆく。

なによりも、知識のかみ砕きは探求であり、ゴールがどこにあるかはわからない。
そのため、開発者はドメインと技術について学習し続ける必要がある。