商品リンクはこちら https://little-hands.booth.pm/items/1835632 DDDはドメインモデリングを通じてソフトウェアの価値を高めようとする設計・開発手法です。 新しく得られたモデルに関する知見を頻繁にコードに落とし込む必要があるのですが、 それはソフトウェアにとっては非常に高い要求をしていることになります。 そこでDDDでは、オブジェクト指向の手法を利用して、メンテナブルで、拡張性の高いコードを書くことを目指しています。 このセッションでは、DDDではモデリング結果をどのようにコードに落とし、どのような利益を得られるのかを、具体的なコードを交えながら解説します。

1. Object-Oriented Conference 2020
DDDはオブジェクト指向を利用して
どのようにメンテナブルなコードを書くか
2020.2.16
松岡 幸一郎 (@little_hand_s)
1

2. 自己紹介
● 松岡 幸一郎 (@little_hand_s)
● DDD community jp主催
● DDD周りの話をするブログ書いてます
● 技術書典8で「ドメイン駆動設計 モデリング/実装ガイド」発売予定
2

3. 質問受け付けます
● app.sli.doにアクセス
● codeに「ooc_matsuoka」を入力
● 質問を追加 or 既存の質問に投票
3

4. 今日お話しすること
4

5. 今日話したいこと
DDDとオブジェクト指向の関係は？
5

6. 今日話したいこと
DDDとオブジェクト指向の関係は？
そもそもDDDって何？
軽量DDDと、そうでないものは何が違うの？
6

7. DDDとは
● DDDとは

8. DDDとは
● DDDとは
抽象的にいうと「ソフトウェア開発手法の一つ」である

9. ● そもそも、ソフトウェアはなんのために作るのか？

10. ● ソフトウェアを適用する対象の何らかの問題を解決するため

11. ● この「ソフトウェアで問題解決しようとする対象」を「ドメイン」と呼ぶ

12. ● DDD：
DomainDrivenDesign(ドメイン駆動設計)の略
● DDD Referenceより
"多くのプロジェクトは、モデリングを行っても
最終的に大きな利益を得られないまま終わります。
DDDは、モデリングから劇的な利益を得られたプロジェクトから、
成功するパターンを抽出します。”

13. (注：DDD Reference)
DomainLanguage.comにあるDDDのエッセンスの要約版
Evans本よりだいぶまとまっているので、定義などに迷ったらまずこちらを参考に

14. ● DDD：
DomainDrivenDesign(ドメイン駆動設計)の略
● DDD Referenceより
"多くのプロジェクトは、モデリングを行っても
最終的に大きな利益を得られないまま終わります。
DDDは、モデリングから劇的な利益を得られたプロジェクトから、
成功するパターンを抽出します。”

15. ● DDDは
「ドメインモデリングによってソフトウェアの価値を高める」
ことを目指す。

16. あれ？

17. あれ？
アーキテクチャ、コード品質の話が出てこない？

18. 「コード品質を上げること」を目的としてDDDを導入検討されることが多いですが
DDDの目的はコード品質のさらに先にあるのです

19. では、コード品質との関係はどうなるのか？
今日はそのつながりも含んだ全体像を示します。

20. ● 「モデル」とはなんでしょうか？
モデルって何？

21. モデルとは？に対する様々な答え
● DBA
「DBのテーブルのこと」
21

22. ● DBA
「DBのテーブルのこと」
● サーバーサイドエンジニア
「テーブルに対応したオブジェクトのこと」
モデルとは？に対する様々な答え
22

23. モデルとは？に対する様々な答え
● DBA
「DBのテーブルのこと」
● サーバーサイドエンジニア
「テーブルに対応したオブジェクトのこと」
● 機械学習エンジニア
「数式のこと」
23

24. モデルとは？
● 「モデル」という言葉は文脈によって大きく違う使われ方をする
● 言葉の定義をしましょう

25. ● model:
A system of abstractions that describes selected aspects of a domain and can
be used to solve problems related to that domain
● モデル：問題解決のために、物事の特定の側面を抽象化したもの
DDD文脈での定義
ざっくり意訳
25

26. モデルの区別
● ドメインモデル：
● データモデル：
26

27. モデルの区別
● ドメインモデル：
ドメインの問題を解決するためのモデル
● データモデル：
27

28. モデルの区別
● ドメインモデル：
ドメインの問題を解決するためのモデル
● データモデル：
データベースに何かを永続化するためのモデル
28

29. モデルの区別
● ドメインモデル：
ドメインの問題を解決するためのモデル
● データモデル：
データベースに何かを永続化するためのモデル
→ これらは別のものであり、明確に区別する必要がある
29

30. ● モデル：問題解決のために、物事の特定の側面を抽象化したもの
→ 抽象化とは何でしょうか？
DDD文脈での定義
30

31. 例：履歴書

32. 例：履歴書 現実には数多くの要素がある
・名前、経歴、志望理由
・写真

33. 例：履歴書 現実には数多くの要素がある
・名前、経歴、志望理由
・写真
・筆跡、筆圧
・紙質、折れ具合

34. 例：履歴書 現実には数多くの要素がある
・名前、経歴、志望理由
・写真
・筆跡、筆圧
・紙質、折れ具合
・履歴書のメーカー
・履歴書の値段
・履歴書を書いた時の気持ち
・：

35. 現実世界の全ての要素をソフトウェアに落とし込むことは不可能

36. 現実世界の全ての要素をソフトウェアに落とし込むことは不可能
→ 必要な要素はモデルに取り込みたい
→ 不要な要素はモデルに取り込みたくない

37. 現実世界の全ての要素をソフトウェアに落とし込むことは不可能
→ 必要な要素はモデルに取り込みたい
→ 不要な要素はモデルに取り込みたくない
この選択が「抽象化」

38. ● 良いモデルとは何か？

39. ● 良いモデルとは何か？
わかりやすいモデル、現実に即しているモデル、拡張性のあるモデル…

40. ● 良いモデルとは何か？
わかりやすいモデル、現実に即しているモデル、拡張性のあるモデル…
→問題解決ができるモデル

41. ● 良いモデルとは何か？
わかりやすいモデル、現実に即しているモデル、拡張性のあるモデル…
→問題解決ができるモデル
● 良くないモデルとは何か？

42. ● 良いモデルとは何か？
わかりやすいモデル、現実に即しているモデル、拡張性のあるモデル…
→問題解決ができるモデル
● 良くないモデルとは何か？
→問題解決ができないモデル
○ 現実に即していない
○ やりたいことができない

43. ● 中途採用における「採用進捗」
現実世界(ドメイン) モデル

44. ● 中途採用における「採用進捗」
現実世界(ドメイン) モデル

45. ● 中途採用における「採用進捗」
現実世界(ドメイン) モデル
書類選考の前に面談
があるのに・・・

46. ● 中途採用における「採用進捗」
現実世界(ドメイン) モデル
書類選考の前に面談
があるのに・・・
面接は3次、4次もある
のに・・・

47. ● 中途採用における「採用進捗」
現実世界(ドメイン) モデル
書類選考の前に面談
があるのに・・・
面接は3次、4次もある
のに・・・
求人関係ない応募も
許可したい・・・

48. ● 中途採用における「採用進捗」
現実世界(ドメイン) モデル
書類選考の前に面談
があるのに・・・
面接は3次、4次もある
のに・・・
求人関係ない応募も
許可したい・・・
運用で
カバー

49. 技術の敗北感がある

50. モデルが良くなくて問題解決できない

51. 運用でカバーできればまだマシ、
売れなければプロダクトがなくなる

52. ● もしも、このソフトウェアが

53. ● もしも、このソフトウェアが
● DDDの実装パターンを的確に使っている
● コードの可読性、拡張性が完璧
● テストも完璧で、バグが全くでない

54. ● もしも、このソフトウェアが
● DDDの実装パターンを的確に使っている
● コードの可読性、拡張性が完璧
● テストも完璧で、バグが全くでない
ものだったとしたら、高い価値を生み出せるか？

55. ● もしも、このソフトウェアが
● DDDの実装パターンを的確に使っている
● コードの可読性、拡張性が完璧
● テストも完璧で、バグが全くでない
ものだったとしたら、高い価値を生み出せるか？
→ NO！！

56. ● モデルがイケてないと、
その後の実装がどんなに素晴らしくても良いソフトウェアにはならない

57. ● 良いモデルを作るにはどうすれば良いか？

58. ● 良いモデルを作るにはどうすれば良いか？
→ドメインに詳しい人から知識を得る

59. ● 良いモデルを作るにはどうすれば良いか？
→ドメインに詳しい人から知識を得る
→運用した知見をモデルにフィードバックして改善する

60. ● 良いモデルを作るにはどうすれば良いか？
→ドメインに詳しい人から知識を得る
→運用した知見をモデルにフィードバックして改善する
→モデルは最初から完成しない、改善していくもの
(DDDとして重要なスタンス)

61. ● モデルは最初から完成しない、改善していくもの
モデル コード

62. ● モデルは最初から完成しない、改善していくもの
モデル コード

63. ● コードとモデルが乖離すると…
モデル コード

64. ● コードとモデルが乖離すると…
○ モデルの更新をコードに正しく反映できているかわからなくなる
モデル コード

65. ● コードとモデルが乖離すると…
○ モデルの更新をコードに正しく反映できているかわからなくなる
○ モデルからコードを理解しにくくなる
モデル コード

66. ● モデルの更新をコードに正しく反映できているかわからない
● コードからモデルを理解しにくい
モデルとコードが乖離すると発生する問題

67. ● モデルの更新をコードに正しく反映できているかわからない
→意図していない実装(=バグ)を産みやすくなる
● コードからモデルを理解しにくい
モデルとコードが乖離すると発生する問題

68. ● モデルの更新をコードに正しく反映できているかわからない
→意図していない実装(=バグ)を産みやすくなる
● コードからモデルを理解しにくい
→ドメインに対する理解もできない
→モデルは改善されない
→ソフトウェアの価値を高めにくくなる
モデルとコードが乖離すると発生する問題

69. ● コードとモデルが乖離すると問題が発生する
● モデルは継続的に改善したい
問題と対策

70. ● コードとモデルが乖離すると問題が発生する
→モデルそのまま表現したコードとなるのが望ましい
● モデルは継続的に改善したい
問題と対策

71. ● コードとモデルが乖離すると問題が発生する
→モデルそのまま表現したコードとなるのが望ましい
→「オブジェクト」でモデルを表現する
● モデルは継続的に改善したい
問題と対策

72. ● コードとモデルが乖離すると問題が発生する
→モデルそのまま表現したコードとなるのが望ましい
→「オブジェクト」でモデルを表現する
● モデルは継続的に改善したい
→コードにも継続的に反映しないと行けない
→頻繁な変更に耐えうるには、拡張性の高い設計が必要
問題と対策

73. ● コードとモデルが乖離すると問題が発生する
→モデルそのまま表現したコードとなるのが望ましい
→「オブジェクト」でモデルを表現する
● モデルは継続的に改善したい
→コードにも継続的に反映しないと行けない
→頻繁な変更に耐えうるには、拡張性の高い設計が必要
→これはソフトウェアとしては非常に高い要求
問題と対策

74. ● コードとモデルが乖離すると問題が発生する
→モデルそのまま表現したコードとなるのが望ましい
→「オブジェクト」でモデルを表現する
● モデルは継続的に改善したい
→コードにも継続的に反映しないと行けない
→頻繁な変更に耐えうるには、拡張性の高い設計が必要
→これはソフトウェアとしては非常に高い要求
→そこで生まれたのがEntityやRepositoryなどのデザインパターン
問題と対策

75. ● 軽量DDD：DDDの実装パターンだけ取り入れること
軽量DDDとは

76. ● 軽量DDD：DDDの実装パターンだけ取り入れること
● 拡張性の高いベストプラクティスを取り入れる
→それだけでも十分価値がある
軽量DDDとは

77. ● 軽量DDD：DDDの実装パターンだけ取り入れること
● 拡張性の高いベストプラクティスを取り入れる
→それだけでも十分価値がある
● コード品質をあげると、ようやくモデリングする余地が生まれる
と考えることもできる
軽量DDDとは

78. ● 軽量DDD：DDDの実装パターンだけ取り入れること
● 拡張性の高いベストプラクティスを取り入れる
→それだけでも十分価値がある
● コード品質をあげると、ようやくモデリングする余地が生まれる
と考えることもできる
● 何の問題もない、
そこからモデリングに踏み出しましょう
軽量DDDとは

79. DDDのアプローチ
DDDのアプローチの全体像

80. DDDのアプローチ
モデルがイケてないと、
実装がどんなに素晴らしくても良いソフトウェアにはならない

81. DDDのアプローチ
モデルを継続的にソフトウェアに反映するために拡張性の高い設計をする

82. どうやってモデリングするのか
82

83. ドメインモデリングの方法
● 一つに決まった方法はない
○ 体系化された手法の例
■ リレーションシップ駆動要件分析(RDRA)
■ ユースケース駆動分析設計
● シンプルな例をご紹介
ユースケース図 / ドメインモデル図によるモデリング
● タスク管理アプリケーションにおける事例で説明する
83

84. ユースケース図
● ユーザーとアプリケーションの相互作用を定義する
● 一般的なUMLのものと同じ
84

85. ユースケース図
● ユーザーとアプリケーションの相互作用を定義する
● 一般的なUMLのものと同じ
85

86. ユースケース図
● ユーザーとアプリケーションの相互作用を定義する
● 一般的なUMLのものと同じ
● 次に続くドメイン図作成の範囲も決める
今回のモデリングのス
コープ
86

87. ● ユースケースの具体化・言語化
○
● ドメインモデル図作成作業の範囲を狭める
○
ユースケース図を作る必要性
87

88. ● ユースケースの具体化・言語化
○ 具体化しないと、どのようなモデルを作ればいいかわからない
○ 「いち作業者として、自分のタスクを管理したい」のか
「管理者として、複数作業者のタスク状況を管理したい」のか
それによって「タスク」のドメインモデルは違うものになる
● ドメインモデル図作成作業の範囲を狭める
○
ユースケース図を作る必要性
88

89. ● ユースケースの具体化・言語化
○ 具体化しないと、どのようなモデルを作ればいいかわからない
○ 「いち作業者として、自分のタスクを管理したい」のか
「管理者として、複数作業者のタスク状況を管理したい」のか
それによって「タスク」のドメインモデルは違うものになる
● ドメインモデル図作成作業の範囲を狭める
○ ドメインモデル図作成をしていると、いろんな要素が思い浮かんでくる
○ 範囲を限定して、限られた時間でまとまった成果を出せるようにする
ユースケース図を作る必要性
89

90. ドメインモデル図
● クラス図の簡易版
● メソッド(振る舞い)は不要
● 属性も代表的なものだけでOK
● 業務の「ルール・制約」(=ドメイン知識) を吹き出しで記述する
● 集約の範囲を明記する
90

91. 集約について
● 集約＝「必ず守りたい強い整合性を持ったオブジェクトのまとまり」
● 必ずまとめて取得して、まとめて更新する単位
● 今回の発表では集約の検討が必要な事例は示せないが、
「このタイミングで集約設計する」ということを覚えておいてください
91

92. 実際のモデリング
● 最初はホワイトボードに殴り書きでOK
92

93. ドメインモデル図
93

94. どうやってコードに落とすか
94

95. まず、形から入る
● レイヤーを定義して「このレイヤにはこういうクラスを作る」というのを決める
● その決まりの上で、とりあえず動くものを書く
● 参考：新卒にも伝わるドメイン駆動設計のアーキテクチャ説明
95

96. ● 改善余地があるコードから入り、リファクタリングしていきます
説明の流れ
96

97. ● この段階では属性の定義のみ、ドメイン知識は持っていない
Taskクラス
97

98. TaskApplicationSericeクラス -タスクを登録する
● ApplicationServiceクラスにタスク登録時の処理を書く
98

99. ● 延期時の処理も同様
TaskApplicationSericeクラス -タスクを延期する
99

100. このコードの問題点
● 不整合なデータをいくらでも作れる
● 仕様を追いかけるのに、複数クラスをコード参照から追っていくしかない
100

101. ドメインモデル図の見直し
● ドメインモデル図の吹き出しの知識はどのクラスに書かれているか？
101

102. TaskApplicationSericeクラス -タスクを登録する
タスクは未完了状態で作成
される
102

103. TaskApplicationSericeクラス -タスクを延期する
タスクは3回だけ、
1日ずつ延期することができる。
103

104. ● ドメインモデル図の知識がApplication層のクラスに書かれている
タスクは未完了状態で作成
される
タスクは3回だけ、
1日ずつ延期することができる。
104

105. ● ドメインモデル図の知識をDomain層のクラス、
特に吹き出しが書かれたオブジェクトに委譲する
タスクは未完了状態で作成
される
タスクは3回だけ、
1日ずつ延期することができる。 105

106. ● 修正前のクラスを再度確認
● このクラスに、吹き出しの知識を委譲する
Taskクラス -Before
106

107. Taskクラス -After (1/3) コンストラクタ
● コンストラクタにタスク作成時の知識を移譲
タスクは未完了状態で作成
される
107

108. Taskクラス -After (2/3) 延期メソッド
● 延期メソッドに延期時の知識を移譲
タスクは3回だけ、
1日ずつ延期することができる。
108

109. Taskクラス -After (3/3) Setter
● Setterがなくなっているので、公開しているメソッド以外で操作できない
109

110. シンプルになったApplicationServiceクラス
● ユースケース記述レベルの抽象度の高いコードのみ残る
110

111. この設計のメリット(1/3)
● 不整合なデータを作れないように強制できる
○ Setter非公開にしたので不整合な値をセットできない
コンパイルエラーになる
111

112. この設計のメリット(2/3)
● 他のルールで生成・更新
されないことが確実になっている
● 1クラスに吹き出しの知識が
凝縮されている
→「このクラスだけ見れば良い」
という大きな安心感を得られる
112

113. この設計のメリット(3/3)
● レイヤーによって書くべきことが決まっている
→コード規約の様に定めて、
実装やレビューの時に使える
● 「俺の考えた最強の設計」同士が戦わなくて済む
113

114. どうやって現場で実践するか
114

115. ● お手本コードを作る
○ ApplicationService、Entity、Repository・・・
● お手本に倣ってコードを書くようにチーム展開する
○ この段階では軽量DDDでも全然OK
● 「あれ、ドメイン層には何を書くべきなんだっけ？」
となったら、ドメインモデリングしてみる
● ドメインモデル図を元にリファクタリングしていく
DDD導入の進め方
115

116. ● 「原理を理解して実践」より、
「お手本を元に展開」の方が圧倒的に難易度が低いため
●
●
なぜお手本コード展開から入るのか
116

117. ● 「原理を理解して実践」より、
「お手本を元に展開」の方が圧倒的に難易度が低いため
● ドメイン層に何を書くべきか？という疑問を持った方が
モデリングの必要性を感じやすいため
●
なぜお手本コード展開から入るのか
117

118. なぜお手本コード展開から入るのか
● 「原理を理解して実践」より、
「お手本を元に展開」の方が圧倒的に難易度が低いため
● ドメイン層に何を書くべきか？という疑問を持った方が
モデリングの必要性を感じやすいため
● 「どういうコードに落としこまれるのか」が
イメージできてからの方が、ドメインモデリングしやすいため
118

119. 上達のイメージ
● DDDのコーディング、モデリング共に1発では上手くできない
コーディング モデリング
119

120. 上達のイメージ
● DDDのコーディング、モデリング共に1発では上手くできない
● コーディングだけ、モデリングだけ上手くなるということもない
コーディング モデリング
120

121. 上達のイメージ
● DDDのコーディング、モデリング共に1発では上手くできない
● コーディングだけ、モデリングだけ上手くなるということもない
● 両方交互に経験値をためながら上達していくしかない
コーディング モデリング
121

122. 上達のイメージ
● DDDのコーディング、モデリング共に1発では上手くできない
● コーディングだけ、モデリングだけ上手くなるということもない
● 両方交互に経験値をためながら上達していくしかない
● 結局、このサイクルのどちらから入るか、という違いだけ
コーディング モデリング
122

123. 上達のイメージ
● DDDのコーディング、モデリング共に1発では上手くできない
● コーディングだけ、モデリングだけ上手くなるということもない
● 両方交互に経験値をためながら上達していくしかない
● 結局、このサイクルのどちらから入るか、という違いだけ
● コーディングと、モデリングを意識的に両方少しずつやってみるのが良い
コーディング モデリング
123

124. まとめ
● DDDでは、「モデルを継続的に改善」「モデルの更新をソフトウェアに反映」のアプロー
チでソフトウェアの価値を高める
● モデルの更新を反映しやすいように、モデルをそのまま表現する
その際にオブジェクト指向の手法を利用する
● DDD戦術設計パターンは、保守性の高い設計のベストプラクティス
● 設計パターンの適用(軽量DDD)と、モデリングを両方使うと、
ソフトウェアの価値を高められる
● 実装と、モデリングを少しずつ着手してみよう
124

125. 最後に・・・
125

126. 宣伝になっちゃいますが。。
「ドメイン駆動設計 モデリング/実装ガイド」
(2020.3.1 技術書典8 オンライン版発売予定)
・本日の内容は1,2章の内容
・全部で11章仕立てです、興味お持ちいただけたら
お買い求めくださいm(_ _)m
・boothで予約受付中
126

127. 質問箱で質問募集しています
● 質問いただければ回答します
● https://peing.net/ja/little_hands
● 「質問箱 little_hands」で検索
127

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

129. sli.do回答タイム
129

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