エリック・エヴァンスのドメイン駆動設計 ２章輪読会に参加して
前回に引き続き参加してきましたので、備忘録を。
前半はユビキタス言語、後半はモデルとは何ぞや？という話だった
ユビキタス言語について nrsさんが以下のように言っていて、すごく納得感があった。
まったく違うものを同じ名前で呼んでた→コンテキストを分ける まったく同じものを違う名前で呼んでた→同じ名前にする まったく同じものを同じ名前で呼んでた→素晴らしい まったく違うものを違う名前で呼んでた→素晴らしい
何が起こるかというと、名前を呼べば、２者が同じものを浮かべるので、齟齬がなくなること。 会話の中でも、モデルの中でも、実装の中でも齟齬がなくなればそればとても素晴らしい。 ユビキタス言語大事。
あと、議論の中でユビキタス言語が周りに説明できないからいい日本語の言い回しないか？という話がでましたが、 ユビキタス言語をそれ以外の言葉を使うと、ユビキタス言語自体に揺らぎがでるので、ひたすらユビキタス言語という言葉を使うことによって習慣から文化で飲み込んでいくしかないのかなと思ったり。
モデルの定義
そもそもモデルってなんだろう？ 第２章を読んで質問をひとつだけあげるならこれでした。
輪読会でも取り上げていただいてたので、大変助かりました。が、油断して晩御飯食べている間に盛り上がっていたので惜しいことをしたな、と。
モデルは図ではない - 忘れがちなので、常々意識したい - ただ疑問が生まれた（モデルとは
モデルとは何ぞや？ ここで適当にぐぐって答えを探したくなりますが、little_handsさんが
「モデル」って、全世界で意味が統一されているわけではなく、文脈によって全然違うものなので、 DDD輪読会としてはDDD文脈の定義を正とするのが良いと思っていまして その定義がevans本末尾の用語集か、DDD Referenceの定義を正とするのが公式採用という意味でいいかなーと思ったりします
という話をしてくださっていて、なるほどなと。わけわからない表現ですが、ドメイン駆動設計のドメインではモデルの定義はevansが定義したものを正としましょう。ということです。 ググればモデルの説明はたくさんでてきますが、それはDDDとは別のドメインで語られているモデルの説明の可能性が高いということなのかなと思いました。
そうじゃないと「僕はこれがモデルだと思います」の決闘！になっちゃうので笑
では、Evansは何と言っているかというと
モデル： ドメインにおける選択された側面を記述し、そのドメインに関連した問題を解決するのに使用できる抽象の体型
公式リファレンスでは
問題解決のために、物事の特定の側面を抽象化したもの
となっています。 ので、この言葉がモデルの定義であり、この言葉が腑に落ちれば、 モデルを理解するということになるのだと思います。
DDDにおけるモデルの定義を理解仕様とする試み
DDDにおけるモデルとは
問題解決のために、物事の特定の側面を抽象化したもの
ということでした。つまりなんなのかと。 思って、少し具体例で考えてみようと思いました。 ここで、気を付けたのは「何であって」「何出ないか」という視点で書いています。これも一つの抽象化なのかもしれませんが。。。
個人的な意見ですが、言い換えると、あるものごと（ドメイン？）があって何か問題解決をしたいときに問題解決に必要でないものを排除し、問題解決に必要なものを取り出し、その取り出したもの同士あるいは、問題解決の関係性を示すとも言えるかなと思いました。
あまり良い例ではありませんが、子供の手押し車があったとします。 この手押し車は物体として存在するので、縦横高さ、素材、形状、金額などが存在しています。
このとき、「ある子供」はこの「子供の手押し車」を使う体形にぴったりかどうか？という問題を取り扱うドメインがあった場合
- 問題解決に必要でないもの:金額、素材、形状
- 問題解決に必要なもの:縦横高さ
- 取り出したもの同士あるいは、問題解決の関係性:子供の身長より縦が小さいか?,横幅は大きすぎないか?など
雑ですが、上記のように様々な手押し車を上記の側面で抽象化すると、その子供か扱えるかどうかがわかります。 すなわち、「問題解決のために、物事の特定の側面を抽象化したもの」になっている。と考えます。 一方、別問題である「子供にとってこの手押し車は安全か？」「予算内でこの手押し車は買えるのか？」などの解決には寄与しません。
また、別のドメインとして「人間」（※大人も含む）がこの「子供の手押し車」は生活の中で安全か？という問題を取り扱うドメインがあった場合は、状況は異なり以下のようになると考えます。
- 問題解決に必要でないもの:金額、縦横高さ
- 問題解決に必要なもの:形状、素材
- 取り出したもの同士あるいは、問題解決の関係性:素材が発がん性があるものかどうか？、形状の角がとがっているかどうか?
雑ですが、上記のように様々な手押し車を上記の側面で抽象化して基準値を設けておけば、「人間」（※大人も含む）がこの「子供の手押し車」は生活の中で安全か？ということがわかります。 すなわち、「問題解決のために、物事の特定の側面を抽象化したもの」になっている。と考えます。（２回目） これも、別問題である「使う体形にぴったりかどうか？」「予算内でこの手押し車は買えるのか？」などの解決には寄与しません。
つまり、当然のことかもしれませんが、同一の物事に対して、「解決したい問題」が変われば、モデルは変わるということになります。言い換えると、物事をそのまま、考えや絵やコードに落とすことはDDDの世界ではモデルではないということになります。
次にモデルは絵なのか問題?
個人的結論を述べておくと、違うと思っていて、議論の中でも違うという意見が多数派だったと思います。 以下のコメントが刺さりました。
なんとなくだけどモデル = オブジェクト図って固定観念からスタートしてしまっていると混乱してる気がする
まさにその通りで、くどいですが、Evansの定義を再掲すると
問題解決のために、物事の特定の側面を抽象化したもの
モデルは抽象表現である。ということになります。 そして抽象表現は文章でも図でも絵画でもいいはずです。
クラス図も、目的を持った抽象化物なんでモデルの一種ですうよね
モデルに、図も、文字列も、含まれると思います 現実世界を抽象化して表現するときにどういう手段を使うか、という話で、それは図かもしれないし文章かもしれない
その通りだなと思いました。
２つのモデルがあったとき（例えば片方が文章で片方がオブジェクト図）に以下の可能性があると考えます。 ①同じ問題解決のための、別の表現 ②異なる問題解決のための表現
業務の中でも同じことを書くけど、絵のほうが伝わりやすい箇所は絵で、文章で列挙するところは列挙して必要ならどちらも、みたいな選択はすると思いますが①はまさにそれかなと思いました。
同じ問題領域だけど、モデルの表現方法はたくさんあって、それは受け手によって使い分けなければならないということなのかなと。
最後に刺さったコメントを列挙して、また３回目に挑みたいと思います。
「モデル」と「モデルの表現」は違うという話、仰る通り
「モデルは見えない」っていうのは凄まじく同意しました
触れられないものがあるのは非常に共感を持てます その上で、それはモデルではないと思ってますー それをなんとかして表現しようとしているからモデル（模型）だと思ってます
