質問への回答(35件)を、ブログにまとめているのでこちらご覧ください https://little-hands.hatenablog.com/entry/2019/08/31/genba_de_ddd 「Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD！ コラボカンファレンス」登壇資料 ブログ：https://little-hands.hatenablog.com/ Twitter：https://twitter.com/little_hand_s 質問箱：https://peing.net/ja/little_hands

1. DDDのモデリングとは何なのか、
そしてどうコードに落とすのか
2019.8.31
松岡 幸一郎 (@little_hand_s)
1

2. 自己紹介
● 松岡 幸一郎 (@little_hand_s)
● DDD community jp主催
● DDD周りの話をするブログ書いてます
2

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

4. 今日解決したいこと
4

5. 今日解決したいこと
モデリングってどうやるのかわからない
5

6. 今日解決したいこと
モデリングとコードがどう繋がるのかわからない
6

7. 今日解決したいこと
どうやって現場で実践するのかわからない
7

8. 今日話すこと
1. DDDにおけるモデリングとは
2. どうやってモデリングするか
3. どうやってコードに落とすか
4. どうやって現場で実践するか
8

9. 1. DDDにおけるモデリングとは
9

10. ● まず、モデルとは？
DDD文脈での定義
10

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

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

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

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

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

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

17. 言葉の定義
● Domain:
A sphere of knowledge, influence, or activity. The subject area to which the
user applies a program is the domain of the software.
● ドメイン：ソフトウェアで問題解決しようとする対象
ざっくり意訳
17

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

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

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

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

22. モデルの区別
● ドメインモデル：
ドメインの問題を解決するためのモデル
● データモデル：
データベースに何かを永続化するためのモデル
→ これらは別のものであり、明確に区別する必要がある
→まずはドメインモデルを作り、
その永続化を実現するためのデータモデルを作る
という形で共存する
22

23. DDDアプローチの全体像
ドメイン
問題
23

24. DDDアプローチの全体像
ドメインモデル
ドメイン
問題
24

25. DDDアプローチの全体像
ドメインモデル
ドメイン
ソフトウェア
問題
25

26. DDDアプローチの全体像
ドメインモデル
ドメイン
ソフトウェア
問題
解決
26
参考：ドメイン駆動設計は何を解決しようとしているのか

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

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

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

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

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

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

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

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

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

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

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

38. ドメインモデル図
38

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

59. なぜお手本コード展開から入るのか
● 「原理を理解して実践」より、
「お手本を元に展開」の方が圧倒的に難易度が低いため
● 「どういうコードに落としこまれるのか」が
イメージできてからの方が、ドメインモデリングしやすいため
59

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

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

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

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

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

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