前編https://qiita.com/katokonn1020/items/767b611e83fc71571c37
からの続きです。
#・ドメインに落とし込むということ
DDDの前提となっている概念があります。
それは、現実の関心をできるだけ開発上とでシンクロさせることです。
例えば
銀行業務システムがあるとします。
この中では、顧客の住所は所持しているでしょうが、顧客の髪の色などは持っていないでしょう。
なぜなら期待されているシステムで、住所は使うかもしれませんが、髪の色は不要だからです。
もう一つ、車製造システムで具体例を出します。
車があります。
車にはハンドルやタイヤが付いています。
その車に対して、タイヤは一種ですが、タイヤはその車だけに使われてるとは限りません。
なので車クラスから保持しているタイヤの種類を返す機能は自然ですが、
そのタイヤから使っている車を返す機能は、現実に即していません。
この様にシステムが持っている関心と、実際のモデルをシンクロさせることが大事です。
必要な関心、不要な関心
それらを取捨選択して、開発して行くことが大切だとエリックは言っているわけですね。
それらを可能な限り正確にやるには、専門家との話し合いが重要です。
#・話し合いという名のモデリング
よりわかりやすくDDDにおけるモデリングを理解するために例を出します。
あなたは航空監視システムを作ることになりました。
なので、実際に空港で働いている専門家を交えてモデリングをすることになりました。
あなた「航空監視システムを作る上で、何から始めればいいでしょうか」
専門家「根本的なことから始めましょうか。まず監視する飛行機は必ず存在します。それらは出発地と到着地を持っています」
あなた「なるほど。到着地につくならどの様なルートを進んでも大丈夫なのですか？」
専門家「いえ、パイロットは勝手にルートを決めてはいけません。必ず航路というのが指示されるのでそれに従います」
あなた「ふむ。航路というのは、ある地点とある地点をつなぐ三次元上の点と考えても良さそうですね」
専門家「私はそうとは考えません。結局は地図上で、緯度と経度で表されるものなので二次元上の点と考えられます」
あなた「わかりました。ではその様な地点を運航定点と表すことにします。とすると出発地も到着地も等しくただの運航定点であるので、特別に扱う必要はなさそうです。ちなみに二次元ということは、航路さえあっていれば高度などは自由ということですか？」
専門家「いえ、維持すべき高度も運航計画によって事前に決められています」
あなた「運航計画？新しいワードですね。何ですかそれは」
専門家「離陸する前に、パイロットは運行計画を受け取ります。運行計画は運行に関する情報を全て含んでいます。航路、維持すべき高度、飛行速度、飛行機の型式、さらには乗務員の情報も運行計画に含まれています。」
あなた「運航計画はかなり重要そうですね。これはモデルに取り入れましょうか」
この例はかなり重要な事柄をいくつも含んでいます。
そのうちの一つにユビキタス言語というものがあります。
#・ユビキタス言語とは
開発者と専門家の間では、同じ概念を保持しているが別の名前を持った言葉がいくつも生まれます。
例えば、漫画ビューワアプリを作成している時に
専門家は「この漫画のこのページにおけるこのコマは」などと話します。
それに対してエンジニアは、聴きながら内面で
「(あるcomicに対して、特定のpageでpanelが)」なんて思ってるわけです。
つまり、現実の一つの関心について
専門領域ワード、開発サイドワードと二つの言葉が生まれてしまっているというわけですね。
この様な事態の解決策として、統一した言葉を用意しようとエリックが提唱したのがユビキタス言語です。
今回の例でいうと
ではその様な地点を運航定点と表すことにします
この運航定点こそがユビキタス言語ですね。
#・モデル駆動設計とモデルをリンクさせた実装
上記の単純な会話でも、専門家と開発者との間にたくさんの齟齬が発生しているのがわかるでしょう。
この様に、一見あなたの頭に思い浮かんだ実装が正しく思えても、実際にドメイン分析して見ると、それは現実に即していないことがわかったりします。
その齟齬をできるだけ排除して、可能な限りドメインに沿った仕様にモデリングしていきましょうというのが今回のお話でした。