DDD 読書会 #1(後半)

前回の第一回の続きです。

1章 Crunching Knowledge

Crunching Knowledgeをそのまま訳すと「知識の咀嚼」となります。「知識(=ドメイン)」を整理して表現した物(=モデル)をそのままプログラムとして反映しよう、というのがドメイン駆動設計のアプローチです。

ただしドメインエキスパートの考えをそのままソフトウェアに反映することはできません。そこで、ドメインエキスパートと開発者達でモデルを作り上げ、洗練し続ける事をドメイン駆動設計では提案しています。これを Knowledge Crunching と表現しています。

この章の最初の部分では「知識の咀嚼」の様子を例をあげて説明しています。ドメインエキスパート(プリント基板の設計者)からヒアリングをして設計していくわけですが…UMLをそのまま見せていたりします。「UMLを見せて分かる人が現実にどれだけいるのか」などと思いましたが、実際にはもっと分かりやすく説明できるのかもしれません。そう言ったノウハウも今後出てくる事を期待するようにします…。

さて、そのように設計をドメインエキスパートと開発者達で作り上げていく作業にどのようなメリットがあるのでしょうか。この章では以下のような点が上げられていました。

ドメインエキスパートによるチェックが入る

対極の例として、いわゆるウォーターフォール型の開発が上げられており、設計のフィードバックをドメインエキスパートから得られないためにうまくいかないと書かれてあります。また、いわゆるアジャイル開発では顧客によるフィードバックが行われる事もありますが、設計には参加しないのでその後の改良までを意識した設計ができない、といった指摘がされていました。

関係者全員がプログラム全体の理解を深めることができる

モデルを洗練させる作業に全員参加する事も重要な点としてあげられています。こうする事で、全員がプログラム全体の理解を深めることができます。実際の所、メンバーの入れ替えが発生すると引き継ぎ時にノウハウが失われる、という指摘があり、これは個人的にかなり思い当たる所です。特に、意図的に素直でない書き方をした場合には引き継ぎ時にはその意図が失われる事が多く、無視されたり逆に無視して、後でその意図に気づく事も多いように思います。

章の最後では、モデルの洗練を続ける事で、隠れた本質を見いだす事ができる、という主張がされていました。初期段階では本質的な問題を認識しているケースはまれで、モデルの洗練を続ける事で当初の意図以上のソフトウェアを作成できるという事が書かれていました。

感想

当初の意図を超える機能まで作り上げるのは難しいとは思います。それどころか、個人的には Knowledge Crunching の前提である顧客との密なやり取りをする機会すらあまり無かったりします。 Knowledge Crunching をうまく行うイメージがつかないのが正直な所です。ただ、ここまでに書かれていた指摘は思い当たる節のある事が多く、また主張に一貫性があって、読んでいて非常に面白いです。まだ10分の1も進んでいないので、今後さらに期待、といった所でしょうか。

…というわけで第1回で進めた部分がまだ消化できませんでした。続きは後日という事で。