第2回福岡DDD勉強会の発表資料です。 http://www.zusaar.com/event/4987003 Domain-Driven Design Quickly http://www.loewenbraeuzelt.de/wp-content/uploads/DomainDrivenDesignQuicklyOnline.pdf http://www.infoq.com/jp/minibooks/domain-driven-design-quickly （日本語版）

1. Domain-Driven Design
Quickly 読書メモ
2.ユビキタス言語
すごく・・・akimicyuです・・・

2. Quicklyの目次
はじめに
イントロダクション
１．ドメイン駆動設計とは何か
２．ユビキタス言語
３．モデル駆動設計
４．リファクタリングのためのさらに深い考察
５．モデルの完全性を維持する
６．今日におけるDDDの諸問題
2

3. 背景(1章を踏まえて)

4. DDDを実践するには？(1/2)
• 「ソフトウェアの専門家」と「ドメインの専門家」
が協力してドメインモデルを作成することが不可欠
• それを阻む「言語の壁」
• プログラムの言葉（クラス、メソッド、アルゴリ
ズム、パターン、……）
• 専門領域の言葉（部外者には理解できない）
4

5. DDDを実践するには？(2/2)
• チームのメンバがドメインについて議論する共通の
言葉を共有していない(両者、好き勝手な言葉を使
用)と、プロジェクトが深刻な問題に直面する
• DDDの核となる原則
• ドメインモデルに基づく言語（→ユビキタス言語
）を使うこと
5

6. ユビキタス言語

7. ユビキタス言語(1/2)
• ドメインモデル(->１章)に基づく言語
• ドメインモデルはソフトウェアとドメインが出会う場所に
あるのだから、共通言語の基板として適切
• チームのメンバに、常にこの言語を用いるよう要求
1. ステークホルダ間でのコミュニケーション
2. 設計文書/図
3. コード記述時の命名等
7

8. ユビキタス言語(2/2)
• ユビキタス言語を用いることで設計の全ての部分が
結びつき、設計チームが効率よく作業するための前
提が生まれる
• ドメイン専門家の注意点：ドメインの表現としてふ
さわしくない用語/モデル構造に反対すること
• ソフトウェア専門家の注意点：設計に紛れ込みやす
い曖昧さや矛盾が現れていないか注視すること
8

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

10. 出発点：飛行機、出発地、目的地
10
ユビキタス言語を創造する(1/6)
専門家 : 基本的なことから始めましょう。どのような飛行
機を監視するにせよ 監視対象の飛行機は必ず存在します。
それぞれの飛行機は出発地から飛び立ち、 目的地に到着し
ます。

11. ユビキタス言語を創造する(2/6)
「航路」の概念が発見される！
開発者 : なるほど、簡単ですね。飛行
しているときに、パイロットは好きな
進 路を選ぶことができるのですか。目
的地に着くのであれば、どの方向へ進
むの かは自分たちの責任で決めてしま
っていいのですか。
専門家 : いいえ、それは違います。パ
イロットには飛ばなければならない航
路 が指示されます。パイロットは可能
な限り、航路に沿って飛行しなければ
なり ません。

12. ユビキタス言語を創造する(3/6)
「航路」を形成する地球平面上の点を「運航定点」と定義
(出発地/目的地は「運航定点」の一種とする)
開発者 : わかりました。ではそのよう
な経度と緯度で決まる点を運行定点と
呼 びましょう。地球上の固定された点
ですからね。それから、航路は2次元
の点 の連なりとして考えましょう。と
すると、出発地も目的地も運行定点で
すから、 特別な概念として考えなくて
もよさそうです。

13. ユビキタス言語を創造する(4/6)
高度の必要性に疑問を持つことから「運行計画」の概念を
発見する！
開発者 : ところで、飛 行機が航路に沿
って飛ばなければならないのはわかり
ましたが、高いところを 飛んだり低い
ところを飛んだりするのは自由にでき
るのですか。
専門家 : いいえ。飛行機が飛んでいる
間に維持すべき高度も運行計画によっ
て 事前に決められています。

14. ユビキタス言語を創造する(5/6)
「運行計画」に気づくことで、システムの監視対象が「飛
行機」ではなく「フライト」であることへの気づきを得る
開発者 : この図のおかげで、気づいたこと
が あります。運行を監視しているときは
、じつは飛行機そのものに関心があるの
ではない、機体の色が白だろうと青だろう
と、機種がボーイングだろうとエア バス
だろうと関係ないということです。関心が
あるのはその飛行機のフライト なのです
。実際に追跡し、計測するのはフライトな
のです。モデルをもっと正 確にするため
に尐し変更する必要がありますね。

15. ユビキタス言語を創造する(6/6)
• とはいえ、先のような対話は冗長で困難。チームの
メンバ全てが共通言語の必要性を自覚し、ユビキタ
ス言語を使うよう徹底されていないと実践は難しい
• 開発者はユビキタス言語で表現された、ドメインモ
デルの主要概念をコードに実装すべき(共通言語と
コードの対応付け)
• 実際にどのように行うかについては、３章参照
15

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

17. ユビキタス言語の表現方法
• チームのメンバに設計上の概念を伝える上で適切な
方法であるなら何でもいい(図、文章、口頭の会話
、コード、……)
• UMLはスケッチ用途には有用だが万能ではない
• 各種方法のトレードオフを意識すること。その際に
は、伝達効率だけでなく保守コストも意識すること
17

18. まとめ

19. まとめ
• ドメインの専門家と協力してドメインモデルを作成
すること
• そのためには、ドメインモデルに基づく共通言語で
あるユビキタス言語を用いることを意識し、チーム
内で徹底すること
• ユビキタス言語の表現方法については、他のステー
クホルダが理解可能なものを選択すること
19

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