「ドメイン駆動設計」を読んだ〜第1章　知識をかみ砕く〜

引き続き「ドメイン駆動設計」を読み進めました。

「第1章　知識をかみ砕く」には、ドメインエキスパートと、開発者の会話を通じてモデルを作り上げていく様子から始まります。

モデルを書いて可視化すること
繰り返し相互のフィードバックでモデルを成長させること
モデルと実装(プロトタイプ)を結びつけて、早期のフィードバックを得ることの重要性
新しい概念を新しいモデルの要素として、抽出・分離すること

といったことが書かれています。

モデル化そのもののテクニックの詳細は書かれていませんが、最初から全ての要素を全て揃えて完全なモデルを書くのではなく、その時点で関心を持っていること（つまり、ドメイン）に集中してモデル化し、(画面等も無いミニマムな)プロトタイピングによりその本質を捉えていることの検証とフィードバックを繰り返しているところが特徴です。

途中、ウォーターフォールにはフィードバックが欠けているために上手くいかないと記載されていますが、上手く行っているウォーターフォールも当然世の中には有るはずで、きっとそのようなプロジェクトでは意識的か、無意識かは別として段階的なモデル化とフィードバックが行われていて、反対に上手く行っていないプロジェクトではプロジェクトルールで規定された成果物を揃えることが目的になっているのではないでしょうか。

最初からすべてをあまねくモデル化しようとしても検証もできないですし、よりよいモデルのためにフィードバックを反映する余地が有りません。

開発者が考える拡張性や保守性は未来を向いていますが、ドメインエキスパートが考える拡張性は過去との連続性に主眼が置かれていて、それらはソフトウェアを作り上げる、という意味では本来相互に補完する関係にあるのではないでしょうか。

本書では詳細は触れられていませんが、フィードバックできる粒度を維持するためにも、実はドメイン駆動設計で最も大事なスキルは「今やらないこと・着目しないことを決める」では？と感じました。