DDD / Ubiquitous Language

ユビキタス言語(P24) †

要約 †

• ユビキタス言語の必要性(共通の言語を持たないことの問題点)
  • ドメイン専門家は自分たちのドメインに関するジャーゴン*1については理解しているが、ソフトウェア開発上の技術的用語については全てを理解しているわけではない。
  • 一方開発者は、説明的・機能的な観点の用語の範囲内でシステムを理解して議論する。しかしそれらの用語には、ドメイン専門家のジャーゴンが含んでいる趣旨や意図が欠けてしまっている。
  • ドメイン専門家と開発者の間で言語の隔たりがあると、ドメイン専門家は自分の要望の説明が曖昧になってしまうし、開発者は新しいドメインについて理解するのに苦労する。

• 共通の言語を持たないプロジェクトでは、専門用語の通訳作業が頻繁に発生し、コミュニケーションが間接化してしまう。
  • 通訳は、開発者とドメイン専門家間のみならず、開発者同士やドメイン専門家同士でのコミュニケーションでも発生する。そのほか、あるドメイン専門家が他の専門家と開発者間のコミュニケーションを仲介をする場合にも通訳作業が発生する
  • 通訳はコミュニケーションを鈍重にするし、知識の咀嚼を欠乏させる。通訳しようと努力すると、かえって知識とアイデアの相互作用を阻害し、深甚なモデルへの洞察を失うことになる。
  • あらゆる通訳作業についてコストがかかるし、厳密さに欠けるため誤解のリスクも高い。

• 共通言語を持たない場合や共通言語が崩壊したときに直面する問題
  • コミュニケーションが間接化し、その結果、各チームメンバーが、同じ用語を異なる意味で使い出してしまう(しかも意味が異なっていることを認識しないで)。
  • 開発者がシステム設計の用語の範囲内で議論しているときに、ドメイン専門家は自分の専門用語を使って議論してしまう。
  • コードに組み込まれる用語と日々の議論で使う用語が切り離されてしまう。
  • 一人の人間でさえも会話内や文章内で異なる言語を使ってしまうようになる。
  • 結果として、ドメインに関する最も鋭い表現は、コードにも文章にも捕捉されずに消えてしまうことになる。

• ユビキタス言語を用いた開発
  • ユビキタス言語とは、チーム全体(開発者とドメイン専門家)で共用する言語であり、あらゆる場面で使われる。
    • コード、図、文書、会話、開発者によるタスクや機能の説明、ドメイン専門家による要件や開発計画や機能特徴(feature)の説明など。
    • 特に日々の会話で使用することが重要である。
  • ユビキタス言語の語彙には、クラスや特徴となるオペレーションの名前が含まれている。
  • ユビキタス言語は、言葉の定義に曖昧さや不整合性がない。
  • もし曖昧さや不整合性が見つかった場合、扱いにくい用語をより理解しやすい用語と置き換えなければならない。
  • ユビキタス言語はモデルがベースとなっている。そのため、モデルに変更があった場合はユビキタス言語にも変更が発生する。
    • 用語の変更は、図の変更、クラス名やメソッド名の変更につながる。用語の意味が変った場合には振る舞いの変更をしなければならない。

• Example：貨物の経路設定

• シナリオ１：ドメインの抽象化が小さい場合

• ユーザ：　さて、通関地点(customs clearance point)を変更する場合、経路計画全体をやり直す必要があります。
• 開発者：　ですね。発送(Shipment)テーブルの貨物ID(Cargo_ID)に該当する全行を削除して、それから出発地(origin)、目的地(destination)、通関地点を経路サービス(Routing Service)に渡しましょう。そうすればテーブルに再投入されます。そうなると貨物(Cargo)のデータが発送テーブル上に存在するかを知るために、貨物にブール値を持たせないといけないですね。
• ユーザ：　全行を削除ですって？わかりました。とにかくそうしましょう。とにかく、もし過去に通関地点を一切持っていなかったら、同様のことをやらなければならないですね。
• 開発者：　もちろん。出発地、目的地、通関地点がどれか1つでも変った時や、初めて通関地点を設定する時は、必ず発送データがあるかをチェックし、削除してから経路サービスに再度作成させましょう。
• ユーザ：　当然ながら、もし古い通関地点が期待する情報であれば、削除と再度作成はしたくないですね。
• 開発者：　まぁ、問題ないです。経路サービスに毎回荷積み(load)と荷降ろし(unload)を再度作成させるのは簡単です。
• ユーザ：　ええ。しかし私たちには他にも業務があって、新規の旅程(itinerary)のための支援計画を全て作らないといけないんです。なので、変更が本当に必要にならない限りは経路の再設定はしたくないんです。
• 開発者：　むむ・・・では初めて通関地点に申告する場合だけ、古い引き継がれた通関地点を探すようにテーブルに問合わせて、新しい通関地点の情報と比較しましょう。そうすれば経路を再設定する必要があるかわかります。
• ユーザ：　旅程が常に変わるかもしれないけど、出発地と目的地の再設定については心配する必要はないです。
• 開発者：　助かります。ではそれについては考慮しません。

• 例題シナリオ２：議論の支援を高めるドメインモデルの場合

• ユーザ：　さて、通関地点(customs clearance point)を変更する場合、経路計画全体をやり直す必要があります。
• 開発者：　ですね。経路詳細(Route Specification)のいずれかの属性を変更する場合、古い旅程(Itinerary)を削除して、新しい経路詳細に基づいた旅程を作成するように経路サービスに依頼しましょう。
• ユーザ：　もし過去に通関地点をまったく指定していなければ、同様のことをやらなければならないですね。
• 開発者：　もちろん、経路詳細(*)*2の属性をどれか変更した時は、旅程を再度作成します。経路詳細には初回の税関申告を含みます。
• ユーザ：　当然ながら、もし古い通関地点が期待する情報であれば、削除と再度作成はしたくないですね。
• 開発者：　まぁ、問題ないです。経路サービスに毎回旅程を再度作成させるのは簡単です。
• ユーザ：　ええ。しかし私たちには他にも業務があって、新規の旅程のための支援計画を全て作らないといけないんです。なので、変更が本当に必要にならない限りは経路の再設定はしたくないんです。
• 開発者：　なるほど。では経路詳細にいくつか機能を追加しましょう。詳細(*)に何か変更があった場合は必ず、旅程が詳細をまだ満たしているかを見てみましょう。もし満たしていなければ、経路サービスで旅程を再設定させましょう。
• ユーザ：　旅程が常に変わるかもしれないけど、出発地と目的地の再設定については心配する必要はないです。
• 開発者：　都合がいいですね。しかし我々にとっては、毎回比較するようにしたほうがよりシンプルでしょうね。経路詳細が満たさなくなった場合だけ、旅程を作成しましょう。

担当者のつぶやき †

• クラス名やメソッド名の変更はIDEのリファクタリング機能でなんとかできそうですが、名前に応じて振舞いも変更するとなると、相当な労力が必要になるのではと思います。良い解決策はあるんでしょうか？
• 常日頃からドメイン専門家と議論を戦わせないと良いモデル・良いユビキタス言語は作れないとなると、ドメイン専門家と接する時間が短くなりがちな自社持ち帰り開発なんかは推奨されない気がします。(オフショアも？)。

• Exampleはドメインモデル/非ドメインモデルの会話の微妙な違いについての例だったので、結局全訳になってしまいました。
• シナリオ２で'Specification'を'Spec'とわざと略記してる意図が良くわかりませんでした。

• 内容や表現に不備がありましたらツッコミよろしくお願いします。

みんなの突っ込み †

まとめ †