Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
DDDのモデリングとは何なのか、
そしてどうコードに落とすのか
2019.8.31
松岡 幸一郎 (@little_hand_s)
1
自己紹介
● 松岡 幸一郎 (@little_hand_s)
● DDD community jp主催
● DDD周りの話をするブログ書いてます
2
質問受け付けます
● app.sli.doにアクセス
● codeに「lh20190831」を入力
● 質問を追加 or 既存の質問に投票
3
今日解決したいこと
4
今日解決したいこと
モデリングってどうやるのかわからない
5
今日解決したいこと
モデリングとコードがどう繋がるのかわからない
6
今日解決したいこと
どうやって現場で実践するのかわからない
7
今日話すこと
1. DDDにおけるモデリングとは
2. どうやってモデリングするか
3. どうやってコードに落とすか
4. どうやって現場で実践するか
8
1. DDDにおけるモデリングとは
9
● まず、モデルとは?
DDD文脈での定義
10
モデルとは?に対する様々な答え
● DBA
「DBのテーブルのこと」
11
● DBA
「DBのテーブルのこと」
● サーバーサイドエンジニア
「テーブルに対応したオブジェクトのこと」
モデルとは?に対する様々な答え
12
モデルとは?に対する様々な答え
● DBA
「DBのテーブルのこと」
● サーバーサイドエンジニア
「テーブルに対応したオブジェクトのこと」
● 機械学習エンジニア
「数式のこと」
13
モデルとは?
● 「モデル」という言葉は文脈によって大きく違う使われ方をする
● 言葉の定義をしましょう
参考情報:DDD Reference
DomainLanguage.comにあるDDDのエッセンスの要約版
Evans本よりだいぶまとまっているので、定義などに迷ったらまずこちらを参考に
15
● model:
A system of abstractions that describes selected aspects of a domain and can
be used to solve problems related to...
言葉の定義
● Domain:
A sphere of knowledge, influence, or activity. The subject area to which the
user applies a program is the ...
モデルの区別
● ドメインモデル:
● データモデル:
18
モデルの区別
● ドメインモデル:
ドメインの問題を解決するためのモデル
● データモデル:
19
モデルの区別
● ドメインモデル:
ドメインの問題を解決するためのモデル
● データモデル:
データベースに何かを永続化するためのモデル
20
モデルの区別
● ドメインモデル:
ドメインの問題を解決するためのモデル
● データモデル:
データベースに何かを永続化するためのモデル
→ これらは別のものであり、明確に区別する必要がある
21
モデルの区別
● ドメインモデル:
ドメインの問題を解決するためのモデル
● データモデル:
データベースに何かを永続化するためのモデル
→ これらは別のものであり、明確に区別する必要がある
→まずはドメインモデルを作り、
 その永続化を実現す...
DDDアプローチの全体像
ドメイン
問題
23
DDDアプローチの全体像
ドメインモデル
ドメイン
問題
24
DDDアプローチの全体像
ドメインモデル
ドメイン
ソフトウェア
問題
25
DDDアプローチの全体像
ドメインモデル
ドメイン
ソフトウェア
問題
解決
26
参考:ドメイン駆動設計は何を解決しようとしているのか
2.どうやってモデリングするのか
27
ドメインモデリングの方法
● 一つに決まった方法はない
○ 体系化された手法の例
■ リレーションシップ駆動要件分析(RDRA)
■ ユースケース駆動分析設計
● シンプルな例をご紹介
ユースケース図 / ドメインモデル図によるモデリング
● ...
ユースケース図
● ユーザーとアプリケーションの相互作用を定義する
● 一般的なUMLのものと同じ
● 次に続くドメインモデリングの範囲も決める
29
ユースケース図
● ユーザーとアプリケーションの相互作用を定義する
● 一般的なUMLのものと同じ
● 次に続くドメインモデリングの範囲も決める
30
ユースケース図
● ユーザーとアプリケーションの相互作用を定義する
● 一般的なUMLのものと同じ
● 次に続くドメインモデリングの範囲も決める
今回のモデリングのス
コープ
31
● ユースケースの具体化・言語化
○
● ドメインモデル図作成作業の範囲を狭める
○
ユースケース図を作る必要性
32
● ユースケースの具体化・言語化
○ 具体化しないと、どのようなモデルを作ればいいかわからない
○ 「いち作業者として、自分のタスクを管理したい」のか
「管理者として、複数作業者のタスク状況を管理したい」のか
それによって「タスク」のドメインモ...
● ユースケースの具体化・言語化
○ 具体化しないと、どのようなモデルを作ればいいかわからない
○ 「いち作業者として、自分のタスクを管理したい」のか
「管理者として、複数作業者のタスク状況を管理したい」のか
それによって「タスク」のドメインモ...
ドメインモデル図
● クラス図の簡易版
● メソッド(振る舞い)は不要
● 属性も代表的なものだけでOK
● 業務の「ルール・制約」(=ドメイン知識) を吹き出しで記述する
● 集約の範囲を明記する
35
集約について
● 集約=「必ず守りたい強い整合性を持ったオブジェクトのまとまり」
● 必ずまとめて取得して、まとめて更新する単位
● 今回の発表では集約の検討が必要な事例は示せないが、
「このタイミングで集約設計する」ということを覚えておいてく...
実際のモデリング
● 最初はホワイトボードに殴り書きでOK
37
ドメインモデル図
38
3.どうやってコードに落とすか
39
まず、形から入る
● レイヤーを定義して「このレイヤにはこういうクラスを作る」というのを決める
● その決まりの上で、とりあえず動くものを書く
● 参考:新卒にも伝わるドメイン駆動設計のアーキテクチャ説明
40
● この段階では属性の定義のみ、ドメイン知識は持っていない
Taskクラス
41
TaskApplicationSericeクラス -タスクを登録する
● ApplicationServiceクラスにタスク登録時の処理を書く
42
● 延期時の処理も同様
TaskApplicationSericeクラス -タスクを延期する
43
このコードの問題点
● 不整合なデータをいくらでも作れる
● 仕様を追いかけるのに、複数クラスをコード参照から追っていくしかない
44
ドメインモデル図の見直し
● ドメインモデル図の吹き出しの知識はどのクラスに書かれているか?
45
TaskApplicationSericeクラス -タスクを登録する
タスクは未完了状態で作成
される
46
TaskApplicationSericeクラス -タスクを延期する
タスクは3回だけ、
1日ずつ延期することができる。
47
● ドメインモデル図の知識がApplication層のクラスに書かれている
タスクは未完了状態で作成
される
タスクは3回だけ、
1日ずつ延期することができる。
48
● ドメインモデル図の知識をDomain層のクラス、
特に吹き出しが書かれたオブジェクトに写す
タスクは未完了状態で作成
される
タスクは3回だけ、
1日ずつ延期することができる。 49
● 修正前のクラスを再度確認
● このクラスに、吹き出しの知識を移譲する
Taskクラス -Before
50
Taskクラス -After (1/3) コンストラクタ
● コンストラクタにタスク作成時の知識を移譲
タスクは未完了状態で作成
される
51
Taskクラス -After (2/3) 延期メソッド
● 延期メソッドに延期時の知識を移譲
タスクは3回だけ、
1日ずつ延期することができる。
52
Taskクラス -After (3/3) Setter
● Setterがなくなっているので、公開しているメソッド以外で操作できない
53
シンプルになったApplicationServiceクラス
● ユースケース記述レベルの抽象度の高いコードのみ残る
54
この実装のメリット(1/2)
● 不整合なデータを作れないように強制できる
○ Setter非公開にしたので不整合な値をセットできない
コンパイルエラーになる
55
この実装のメリット(2/2)
● 他のルールで生成・更新
されないことが確実になっている
● 1クラスに吹き出しの知識が
凝縮されている
→「このクラスだけ見れば良い」
という大きな安心感を得られる
56
4.どうやって現場で実践するか
57
● お手本コードを作る
○ ApplicationService(UseCase)、Entity、Repository・・・
● お手本に倣ってコードを書くようにチーム展開する
○ この段階では軽量DDDでも全然OK
● 書くのになれたら、ドメ...
なぜお手本コード展開から入るのか
● 「原理を理解して実践」より、
「お手本を元に展開」の方が圧倒的に難易度が低いため
● 「どういうコードに落としこまれるのか」が
イメージできてからの方が、ドメインモデリングしやすいため
59
上達のイメージ
● DDDのコーディング、モデリング共に1発では上手くできない
コーディング モデリング
60
上達のイメージ
● DDDのコーディング、モデリング共に1発では上手くできない
● コーディングだけ、モデリングだけ上手くなるということもない
コーディング モデリング
61
上達のイメージ
● DDDのコーディング、モデリング共に1発では上手くできない
● コーディングだけ、モデリングだけ上手くなるということもない
● 両方交互に経験値をためながら上達していくしかない
コーディング モデリング
62
上達のイメージ
● DDDのコーディング、モデリング共に1発では上手くできない
● コーディングだけ、モデリングだけ上手くなるということもない
● 両方交互に経験値をためながら上達していくしかない
● どちらからこのサイクルを初めてもよいが、
...
ご静聴ありがとうございました
64
質問箱で質問募集しています
● 質問いただければ回答します
● https://peing.net/ja/little_hands
● 「質問箱 little_hands」で検索
65
You’ve finished this document.
Download and read it offline.
Upcoming SlideShare
What to Upload to SlideShare
Next
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

Share

DDDのモデリングとは何なのか、 そしてどうコードに落とすのか

Download to read offline

質問への回答(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

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

DDDのモデリングとは何なのか、 そしてどうコードに落とすのか

  1. 1. DDDのモデリングとは何なのか、 そしてどうコードに落とすのか 2019.8.31 松岡 幸一郎 (@little_hand_s) 1
  2. 2. 自己紹介 ● 松岡 幸一郎 (@little_hand_s) ● DDD community jp主催 ● DDD周りの話をするブログ書いてます 2
  3. 3. 質問受け付けます ● app.sli.doにアクセス ● codeに「lh20190831」を入力 ● 質問を追加 or 既存の質問に投票 3
  4. 4. 今日解決したいこと 4
  5. 5. 今日解決したいこと モデリングってどうやるのかわからない 5
  6. 6. 今日解決したいこと モデリングとコードがどう繋がるのかわからない 6
  7. 7. 今日解決したいこと どうやって現場で実践するのかわからない 7
  8. 8. 今日話すこと 1. DDDにおけるモデリングとは 2. どうやってモデリングするか 3. どうやってコードに落とすか 4. どうやって現場で実践するか 8
  9. 9. 1. DDDにおけるモデリングとは 9
  10. 10. ● まず、モデルとは? DDD文脈での定義 10
  11. 11. モデルとは?に対する様々な答え ● DBA 「DBのテーブルのこと」 11
  12. 12. ● DBA 「DBのテーブルのこと」 ● サーバーサイドエンジニア 「テーブルに対応したオブジェクトのこと」 モデルとは?に対する様々な答え 12
  13. 13. モデルとは?に対する様々な答え ● DBA 「DBのテーブルのこと」 ● サーバーサイドエンジニア 「テーブルに対応したオブジェクトのこと」 ● 機械学習エンジニア 「数式のこと」 13
  14. 14. モデルとは? ● 「モデル」という言葉は文脈によって大きく違う使われ方をする ● 言葉の定義をしましょう
  15. 15. 参考情報:DDD Reference DomainLanguage.comにあるDDDのエッセンスの要約版 Evans本よりだいぶまとまっているので、定義などに迷ったらまずこちらを参考に 15
  16. 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. 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. モデルの区別 ● ドメインモデル: ● データモデル: 18
  19. 19. モデルの区別 ● ドメインモデル: ドメインの問題を解決するためのモデル ● データモデル: 19
  20. 20. モデルの区別 ● ドメインモデル: ドメインの問題を解決するためのモデル ● データモデル: データベースに何かを永続化するためのモデル 20
  21. 21. モデルの区別 ● ドメインモデル: ドメインの問題を解決するためのモデル ● データモデル: データベースに何かを永続化するためのモデル → これらは別のものであり、明確に区別する必要がある 21
  22. 22. モデルの区別 ● ドメインモデル: ドメインの問題を解決するためのモデル ● データモデル: データベースに何かを永続化するためのモデル → これらは別のものであり、明確に区別する必要がある →まずはドメインモデルを作り、  その永続化を実現するためのデータモデルを作る  という形で共存する 22
  23. 23. DDDアプローチの全体像 ドメイン 問題 23
  24. 24. DDDアプローチの全体像 ドメインモデル ドメイン 問題 24
  25. 25. DDDアプローチの全体像 ドメインモデル ドメイン ソフトウェア 問題 25
  26. 26. DDDアプローチの全体像 ドメインモデル ドメイン ソフトウェア 問題 解決 26 参考:ドメイン駆動設計は何を解決しようとしているのか
  27. 27. 2.どうやってモデリングするのか 27
  28. 28. ドメインモデリングの方法 ● 一つに決まった方法はない ○ 体系化された手法の例 ■ リレーションシップ駆動要件分析(RDRA) ■ ユースケース駆動分析設計 ● シンプルな例をご紹介 ユースケース図 / ドメインモデル図によるモデリング ● タスク管理アプリケーションにおける事例で説明する 28
  29. 29. ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ ● 次に続くドメインモデリングの範囲も決める 29
  30. 30. ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ ● 次に続くドメインモデリングの範囲も決める 30
  31. 31. ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ ● 次に続くドメインモデリングの範囲も決める 今回のモデリングのス コープ 31
  32. 32. ● ユースケースの具体化・言語化 ○ ● ドメインモデル図作成作業の範囲を狭める ○ ユースケース図を作る必要性 32
  33. 33. ● ユースケースの具体化・言語化 ○ 具体化しないと、どのようなモデルを作ればいいかわからない ○ 「いち作業者として、自分のタスクを管理したい」のか 「管理者として、複数作業者のタスク状況を管理したい」のか それによって「タスク」のドメインモデルは違うものになる ● ドメインモデル図作成作業の範囲を狭める ○ ユースケース図を作る必要性 33
  34. 34. ● ユースケースの具体化・言語化 ○ 具体化しないと、どのようなモデルを作ればいいかわからない ○ 「いち作業者として、自分のタスクを管理したい」のか 「管理者として、複数作業者のタスク状況を管理したい」のか それによって「タスク」のドメインモデルは違うものになる ● ドメインモデル図作成作業の範囲を狭める ○ ドメインモデル図作成をしていると、いろんな要素が思い浮かんでくる ○ 範囲を限定して、限られた時間でまとまった成果を出せるようにする ユースケース図を作る必要性 34
  35. 35. ドメインモデル図 ● クラス図の簡易版 ● メソッド(振る舞い)は不要 ● 属性も代表的なものだけでOK ● 業務の「ルール・制約」(=ドメイン知識) を吹き出しで記述する ● 集約の範囲を明記する 35
  36. 36. 集約について ● 集約=「必ず守りたい強い整合性を持ったオブジェクトのまとまり」 ● 必ずまとめて取得して、まとめて更新する単位 ● 今回の発表では集約の検討が必要な事例は示せないが、 「このタイミングで集約設計する」ということを覚えておいてください 36
  37. 37. 実際のモデリング ● 最初はホワイトボードに殴り書きでOK 37
  38. 38. ドメインモデル図 38
  39. 39. 3.どうやってコードに落とすか 39
  40. 40. まず、形から入る ● レイヤーを定義して「このレイヤにはこういうクラスを作る」というのを決める ● その決まりの上で、とりあえず動くものを書く ● 参考:新卒にも伝わるドメイン駆動設計のアーキテクチャ説明 40
  41. 41. ● この段階では属性の定義のみ、ドメイン知識は持っていない Taskクラス 41
  42. 42. TaskApplicationSericeクラス -タスクを登録する ● ApplicationServiceクラスにタスク登録時の処理を書く 42
  43. 43. ● 延期時の処理も同様 TaskApplicationSericeクラス -タスクを延期する 43
  44. 44. このコードの問題点 ● 不整合なデータをいくらでも作れる ● 仕様を追いかけるのに、複数クラスをコード参照から追っていくしかない 44
  45. 45. ドメインモデル図の見直し ● ドメインモデル図の吹き出しの知識はどのクラスに書かれているか? 45
  46. 46. TaskApplicationSericeクラス -タスクを登録する タスクは未完了状態で作成 される 46
  47. 47. TaskApplicationSericeクラス -タスクを延期する タスクは3回だけ、 1日ずつ延期することができる。 47
  48. 48. ● ドメインモデル図の知識がApplication層のクラスに書かれている タスクは未完了状態で作成 される タスクは3回だけ、 1日ずつ延期することができる。 48
  49. 49. ● ドメインモデル図の知識をDomain層のクラス、 特に吹き出しが書かれたオブジェクトに写す タスクは未完了状態で作成 される タスクは3回だけ、 1日ずつ延期することができる。 49
  50. 50. ● 修正前のクラスを再度確認 ● このクラスに、吹き出しの知識を移譲する Taskクラス -Before 50
  51. 51. Taskクラス -After (1/3) コンストラクタ ● コンストラクタにタスク作成時の知識を移譲 タスクは未完了状態で作成 される 51
  52. 52. Taskクラス -After (2/3) 延期メソッド ● 延期メソッドに延期時の知識を移譲 タスクは3回だけ、 1日ずつ延期することができる。 52
  53. 53. Taskクラス -After (3/3) Setter ● Setterがなくなっているので、公開しているメソッド以外で操作できない 53
  54. 54. シンプルになったApplicationServiceクラス ● ユースケース記述レベルの抽象度の高いコードのみ残る 54
  55. 55. この実装のメリット(1/2) ● 不整合なデータを作れないように強制できる ○ Setter非公開にしたので不整合な値をセットできない コンパイルエラーになる 55
  56. 56. この実装のメリット(2/2) ● 他のルールで生成・更新 されないことが確実になっている ● 1クラスに吹き出しの知識が 凝縮されている →「このクラスだけ見れば良い」 という大きな安心感を得られる 56
  57. 57. 4.どうやって現場で実践するか 57
  58. 58. ● お手本コードを作る ○ ApplicationService(UseCase)、Entity、Repository・・・ ● お手本に倣ってコードを書くようにチーム展開する ○ この段階では軽量DDDでも全然OK ● 書くのになれたら、ドメインモデリングしてみる ● ドメインモデル図を元にリファクタリングしていく DDD導入の進め方 58
  59. 59. なぜお手本コード展開から入るのか ● 「原理を理解して実践」より、 「お手本を元に展開」の方が圧倒的に難易度が低いため ● 「どういうコードに落としこまれるのか」が イメージできてからの方が、ドメインモデリングしやすいため 59
  60. 60. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない コーディング モデリング 60
  61. 61. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない コーディング モデリング 61
  62. 62. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ● 両方交互に経験値をためながら上達していくしかない コーディング モデリング 62
  63. 63. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ● 両方交互に経験値をためながら上達していくしかない ● どちらからこのサイクルを初めてもよいが、 コーディングの方がとっつきやすい コーディング モデリング 63
  64. 64. ご静聴ありがとうございました 64
  65. 65. 質問箱で質問募集しています ● 質問いただければ回答します ● https://peing.net/ja/little_hands ● 「質問箱 little_hands」で検索 65
  • TakuyaSuenaga

    Aug. 10, 2021
  • yutatasaka

    May. 14, 2021
  • HirokiOgata3

    Apr. 14, 2021
  • MioMaeda1

    Nov. 21, 2020
  • RyotaroMorikatsu

    Oct. 21, 2020
  • GentoMorikawa1

    Sep. 9, 2020
  • chamibluemoon

    Aug. 26, 2020
  • yas62kuro

    Jul. 24, 2020
  • kohei916

    Jul. 8, 2020
  • KotaUtashiro

    Jun. 25, 2020
  • ssuserbfce2b

    May. 4, 2020
  • TomokoHayashi4

    Jan. 22, 2020
  • gokoukotori

    Sep. 21, 2019
  • YuichiroIto1

    Sep. 6, 2019
  • tzm_freedom

    Sep. 2, 2019
  • silverrin

    Sep. 2, 2019
  • yyh-gl

    Sep. 2, 2019
  • nishikawas

    Sep. 2, 2019
  • 36ra3

    Sep. 1, 2019
  • HiroshiShiobara

    Sep. 1, 2019

質問への回答(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

Views

Total views

39,323

On Slideshare

0

From embeds

0

Number of embeds

21,448

Actions

Downloads

65

Shares

0

Comments

0

Likes

28

×