Domain-Driven Design Quickly 読書メモ

2.ユビキタス言語

すごく・・・akimicyuです・・・

Quicklyの目次

はじめに

イントロダクション

１．ドメイン駆動設計とは何か

２．ユビキタス言語

３．モデル駆動設計

４．リファクタリングのためのさらに深い考察

５．モデルの完全性を維持する

６．今日におけるDDDの諸問題

2

背景(1章を踏まえて)

DDDを実践するには？(1/2)

• 「ソフトウェアの専門家」と「ドメインの専門家」が協力してドメインモデルを作成することが不可欠

• それを阻む「言語の壁」

• プログラムの言葉（クラス、メソッド、アルゴリズム、パターン、……）

• 専門領域の言葉（部外者には理解できない）

4

DDDを実践するには？(2/2)

• チームのメンバがドメインについて議論する共通の言葉を共有していない(両者、好き勝手な言葉を使用)と、プロジェクトが深刻な問題に直面する

• DDDの核となる原則

• ドメインモデルに基づく言語（→ユビキタス言語）を使うこと

5

ユビキタス言語

ユビキタス言語(1/2)

• ドメインモデル(->１章)に基づく言語

• ドメインモデルはソフトウェアとドメインが出会う場所にあるのだから、共通言語の基板として適切

• チームのメンバに、常にこの言語を用いるよう要求

1. ステークホルダ間でのコミュニケーション

2. 設計文書/図

3. コード記述時の命名等

7

ユビキタス言語(2/2)

• ユビキタス言語を用いることで設計の全ての部分が結びつき、設計チームが効率よく作業するための前提が生まれる

• ドメイン専門家の注意点：ドメインの表現としてふさわしくない用語/モデル構造に反対すること

• ソフトウェア専門家の注意点：設計に紛れ込みやすい曖昧さや矛盾が現れていないか注視すること

8

ユビキタス言語を創造する(航空監視プロジェクトの例)

出発点：飛行機、出発地、目的地

10

ユビキタス言語を創造する(1/6)

専門家 : 基本的なことから始めましょう。とのような飛行機を監視するにせよ監視対象の飛行機は必す存在します。それそれの飛行機は出発地から飛び立ち、目的地に到着します。

ユビキタス言語を創造する(2/6)

「航路」の概念が発見される！

開発者 : なるほと、簡単ですね。飛行しているときに、パイロットは好きな進路を選ふことができるのですか。目的地に着くのであれは、との方向へ進むのかは自分たちの責任で決めてしまっていいのですか。

専門家 : いいえ、それは違います。パイロットには飛はなけれはならない航路が指示されます。パイロットは可能な限り、航路に沿って飛行しなけれはなりません。

ユビキタス言語を創造する(3/6)

「航路」を形成する地球平面上の点を「運航定点」と定義(出発地/目的地は「運航定点」の一種とする)

開発者 : わかりました。ではそのような経度と緯度で決まる点を運行定点と呼びましょう。地球上の固定された点ですからね。それから、航路は2次元の点の連なりとして考えましょう。とすると、出発地も目的地も運行定点ですから、特別な概念として考えなくてもよさそうです。

ユビキタス言語を創造する(4/6)

高度の必要性に疑問を持つことから「運行計画」の概念を発見する！

開発者 : ところで、飛行機が航路に沿って飛はなけれはならないのはわかりましたが、高いところを飛んだり低いところを飛んだりするのは自由にできるのですか。

専門家 : いいえ。飛行機が飛んでいる間に維持すへき高度も運行計画によって事前に決められています。

ユビキタス言語を創造する(5/6)

「運行計画」に気づくことで、システムの監視対象が「飛行機」ではなく「フライト」であることへの気づきを得る

開発者 : この図のおかけで、気づいたことがあります。運行を監視しているときは、じつは飛行機そのものに関心があるのではない、機体の色が白だろうと青だろうと、機種がホーイングだろうとエアバスだろうと関係ないということです。関心があるのはその飛行機のフライトなのです。実際に追跡し、計測するのはフライトなのです。モデルをもっと正確にするために尐し変更する必要がありますね。

ユビキタス言語を創造する(6/6)

• とはいえ、先のような対話は冗長で困難。チームのメンバ全てが共通言語の必要性を自覚し、ユビキタス言語を使うよう徹底されていないと実践は難しい

• 開発者はユビキタス言語で表現された、ドメインモデルの主要概念をコードに実装すへき(共通言語とコードの対応付け)

• 実際にとのように行うかについては、３章参照

15

ユビキタス言語の表現方法

ユビキタス言語の表現方法

• チームのメンバに設計上の概念を伝える上で適切な方法であるなら何でもいい(図、文章、口頭の会話、コード、……)

• UMLはスケッチ用途には有用だが万能ではない

• 各種方法のトレードオフを意識すること。その際には、伝達効率だけでなく保守コストも意識すること

17

まとめ

まとめ

• ドメインの専門家と協力してドメインモデルを作成すること

• そのためには、ドメインモデルに基づく共通言語であるユビキタス言語を用いることを意識し、チーム内で徹底すること

• ユビキタス言語の表現方法については、他のステークホルダが理解可能なものを選択すること

19

ご静聴ありがとうございました