DDD 読書会 #2(前半)
地震で日本が大変なことになってしまいましたが、DDD読書会の内容を進めていきたいと思います。しかしまだ第2回とは…。
第2回ではPart 1の最後の章からPart 2の始めまで進めました。長くなってしまったので分割します。
3章 Binding Model and Implementation
Part 1の最後である3章は、ドメイン駆動設計で最後の重要な要素である「モデルと実装を一致させる」という話です。ユビキタス言語で定義されたモデルを実装にそのまま反映することを、モデル駆動設計と呼んでいます。
「モデル」とは?
…実は、参加者の方から「ここで言うモデルとは何か?」という質問があり、議論になりました。ここまで当然のように読み進めてしまっていましたが、意外ときちんと把握していませんでした…。
結論としては、ドメインを具体的に表現したもの(wikipedia:モデル (自然科学))と考えてよいと思います。
ポイントは、「ドメインの表現」以上の意味を持たせない事です。DBやメモリ、外部システムの仕様等の実装上の概念が(表面には)入りません。モデルはユビキタス言語の用語集として使われるので、実装上の概念を入れるとユビキタス言語に使用できなくなってしまいます。
また、ドメインをオブジェクトのメタファーで表現する必要もありません。例えば、数学的な事象を扱うドメインでは、オブジェクトとはあまり相性が良くありません。この場合、実装には関数型や論理型のプログラミング言語の方が向いているかもしれません。
ただし、これは後の章に書かれてあるのですが、現実的にはオブジェクト指向のパラダイムを元にしたモデルが主流になるそうです。
「設計者は開発に参加するべき」
実際に開発する時は、以下のような流れになることが多いようです。
- 初期段階でモデルを設計担当の人が作成
- 開発担当がそれに従ってコーディング
しかし、この方法は以下のようになり、うまく適用されなくなってしまいます。
- 実装上の制限を初期段階で見通すのは難しく、最初のモデルには実装上の欠陥が見つかる
- この段階でモデルを修正する事は余計なコストがかかる
- 開発現場では次第に設計を無視した(行き当たりばったりの)実装へ
- すると、モデルが参照されなくなってしまい、設計者と実装者のやり取りが行われなくなる
- 最終的にその場しのぎの設計が促進される
また実装経験の豊富な人がうまく設計を行ったとしても、その設計意図が伝わらず、やはり先を考えない実装がされてしまうケースも多いようです。
何が問題なのでしょうか? 本書では「設計作業と実装作業を分担してしまう事」だとしています。そもそも実装というのは設計をコードに反映することではなく、設計そのものです。設計を行う人も実際に開発に参加するべきなのです。
なお、この章の後半のセクションは「ハンズオンモデラー」というタイトルです。はっきりとは書かれていなかったように思いますが、「設計者と開発者を区別しない」ということではなく、スキルのある開発者が他の開発者の面倒を見るイメージなのではないかと思います。
感想
パッと気になったのは、設計担当の分離にはそれなりの根拠があるのではないか、という事です。結構な割合の人が「設計担当はスキルがある人がやるので、コーディングの他にやるべき重要なことが沢山ある」と考えるのではないかと思います。
この疑問に関しての答えは、残念ながら見つけられませんでした。ただ、こう言った考えの根底には「実装は設計の翻訳という単純作業である」という考えがありそうです。ドメイン駆動設計では実装は設計作業なので、その認識があっていないと話がかみ合わないかもしれません。
とはいえ、モデリングと実装を明確に分けている開発現場というのは良く聞く話なのですが、個人的な経験を言うとあまり見たことがありません。特に最近はあまり仕様を決めないで実装者が設計もする事が多いです。アジャイル開発の採用というより単なる人件費の問題みたいですが…。
そんな中よく思うのは、「分析や設計といった『抽象化の作業』は意外と時間がかかる」という事です。抽象化に時間がかかることは一般的によくある事らしく、「分析麻痺」という言葉があるくらいです。早い段階で最低限の設計を終わらせてから、実装と設計のサイクルをまわしていくのが理想だと思うのですが、下手に設計してしまうと、修正が難しくなってしまうこともあります。
このような状況を踏まえると、初期のモデルは最終的なモデルに矛盾しないサブセットになるべく近づけたい訳です。その方法があると良いなあ、等とつらつら考えたのですが…。結局「パターンを知る」「経験を積む」という普通の結論になってしまいました。
ちなみに、この先の Part 2 ではパターンについて書かれてあります。乞うご期待。
