Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8

8.196 Aufrufe

Veröffentlicht am

ドメイン駆動設計 モデリング/実装ガイド
https://little-hands.booth.pm/items/1835632

発売記念に、本書の1,2章の内容を中心にDDDの概要について解説する勉強会です。

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8

  1. 1. 2020.3.8 松岡 幸一郎 (@little_hand_s) 1 ドメイン駆動設計 モデリング/実装入門 勉強会
  2. 2. 自己紹介 ● 松岡 幸一郎 (@little_hand_s) ● DDD community jp主催 ● DDD周りの話をするブログ書いてます ● WEB+DB PRESS 2019年10月号 特集「体験ドメイン駆動設計」執筆 2
  3. 3. 本日の趣旨 3 ● 「ドメイン駆動設計 モデリング/実装ガイド」 技術書典8向けに執筆 ● 発売記念として、本書の一部内容+αを オンライン講義形式で解説します
  4. 4. ● オンラインで既存のオフライン勉強会をどの程度代替できるか、 の検証としての試み オンライン勉強会というチャレンジ オフライン勉強会 ● 前に立って発表 ● Twitterのハッシュタグツイート ● Sli.doによる質疑応答 ● 登壇後の個別質問 4 オンライン勉強会 ● ● ● ●
  5. 5. ● オンラインで既存のオフライン勉強会をどの程度代替できるか、 の検証としての試み オンライン勉強会というチャレンジ オフライン勉強会 ● 前に立って発表 ● Twitterのハッシュタグツイート ● Sli.doによる質疑応答 ● 登壇後の個別質問 5 オンライン勉強会 ● YouTube Liveによる配信 ● ● ●
  6. 6. ● オンラインで既存のオフライン勉強会をどの程度代替できるか、 の検証としての試み オンライン勉強会というチャレンジ オフライン勉強会 ● 前に立って発表 ● Twitterのハッシュタグツイート ● Sli.doによる質疑応答 ● 登壇後の個別質問 6 オンライン勉強会 ● YouTube Liveによる配信 ● Twitterのハッシュタグツイート ● Sli.doによる質疑応答 ●
  7. 7. ● オンラインで既存のオフライン勉強会をどの程度代替できるか、 の検証としての試み オンライン勉強会というチャレンジ オフライン勉強会 ● 前に立って発表 ● Twitterのハッシュタグツイート ● Sli.doによる質疑応答 ● 登壇後の個別質問 7 オンライン勉強会 ● YouTube Liveによる配信 ● Twitterのハッシュタグツイート ● Sli.doによる質疑応答 ● YouTube Liveのチャットによる質問 やりとり
  8. 8. 質問受け付けます ● sli.doで質問受け付けます ○ https://app.sli.do/event/imvxc56h にアクセス ○ 質問を追加 or 既存の質問に投票 8
  9. 9. 質問受け付けます ● sli.doで質問受け付けます ○ https://app.sli.do/event/imvxc56h にアクセス ○ 質問を追加 or 既存の質問に投票 ● ツイートは通常のイベントのようにお願いします ○ Twitterハッシュタグは #ddd_guide ○ YouTube Live上のコメントもOK 9
  10. 10. 不慣れな点も多々ありますが、お付き合いお願いいたします 10
  11. 11. スポンサーご紹介 11
  12. 12. GOLD
 スポンサー
  13. 13. 予算策定のGitHub を開発
 実績/調達
 技術スタック
 シンガポールの
 VCから調達

  14. 14. ログラスDDD勉強会を開催しました!|坂本龍太: Loglass|note 

  15. 15. 今日話す内容 15
  16. 16. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル 話す内容 16
  17. 17. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル ● モデリングから実装まで ○ ドメインモデリングの方法 ○ ドメインモデルを実装に落とす ○ ライブコーディング 話す内容 17
  18. 18. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル ● モデリングから実装まで ○ ドメインモデリングの方法 ○ ドメインモデルを実装に落とす ○ ライブコーディング ● プロジェクトへの導入方法のススメ 話す内容 18
  19. 19. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル ● モデリングから実装まで ○ ドメインモデリングの方法 ○ ドメインモデルを実装に落とす ○ ライブコーディング ● プロジェクトへの導入方法のススメ ● 「ドメイン駆動設計 モデリング/実装ガイド」他の章の紹介 話す内容 19
  20. 20. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル ● モデリングから実装まで ○ ドメインモデリングの方法 ○ ドメインモデルを実装に落とす ○ ライブコーディング ● プロジェクトへの導入方法のススメ ● 「ドメイン駆動設計 モデリング/実装ガイド」他の章の紹介 話す内容 20 1章より
  21. 21. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル ● モデリングから実装まで ○ ドメインモデリングの方法 ○ ドメインモデルを実装に落とす ○ ライブコーディング ● プロジェクトへの導入方法のススメ ● 「ドメイン駆動設計 モデリング/実装ガイド」他の章の紹介 話す内容 21 1章より 2章より
  22. 22. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル ● モデリングから実装まで ○ ドメインモデリングの方法 ○ ドメインモデルを実装に落とす ○ ライブコーディング ● プロジェクトへの導入方法のススメ ● 「ドメイン駆動設計 モデリング/実装ガイド」他の章の紹介  話す内容 22 1章より 2章より 3~11章
  23. 23. 資料公開 ● サンプルコード ○ GitHubにて公開中 ● 資料 ○ こちらにて公開中 23
  24. 24. 今日のゴール 24
  25. 25. ● DDDの概要、開発の流れを理解する 今日のゴール
  26. 26. ● DDDの概要、開発の流れを理解する ● DDD、そんなに難しくないと思えるようになる 今日のゴール
  27. 27. 今日のゴール ● DDDの概要、開発の流れを理解する ● DDD、そんなに難しくないと思えるようになる ● DDDについてもっと知りたくなる
  28. 28. DDDとは 28
  29. 29. DDDとは ● DDDとは
  30. 30. DDDとは ● DDDとは 抽象的にいうと「ソフトウェア開発手法の一つ」である
  31. 31. ● そもそも、ソフトウェアはなんのために作るのか?
  32. 32. ● ソフトウェアを適用する対象の何らかの問題を解決するため
  33. 33. ● この「ソフトウェアで問題解決しようとする対象」を「ドメイン」と呼ぶ
  34. 34. ● DDD: DomainDrivenDesign(ドメイン駆動設計)の略 ● DDD Referenceより "多くのプロジェクトは、モデリングを行っても 最終的に大きな利益を得られないまま終わります。 DDDは、モデリングから劇的な利益を得られたプロジェクトから、 成功するパターンを抽出します。”
  35. 35. (注:DDD Reference) DomainLanguage.comにあるDDDのエッセンスの要約版 Evans本よりだいぶまとまっているので、定義などに迷ったらまずこちらを参考に
  36. 36. ● DDD: DomainDrivenDesign(ドメイン駆動設計)の略 ● DDD Referenceより "多くのプロジェクトは、モデリングを行っても 最終的に大きな利益を得られないまま終わります。 DDDは、モデリングから劇的な利益を得られたプロジェクトから、 成功するパターンを抽出します。”
  37. 37. ● DDDは 「ドメインモデリングによってソフトウェアの価値を高める」 ことを目指す。
  38. 38. あれ?
  39. 39. あれ? アーキテクチャ、コード品質の話が出てこない?
  40. 40. 「コード品質を上げること」を目的としてDDDを導入検討されることが多いですが DDDの目的はコード品質のさらに先にあるのです
  41. 41. では、コード品質との関係はどうなるのか? 今日はそのつながりも含んだ全体像を示します。
  42. 42. ● 「モデル」とはなんでしょうか? モデルって何?
  43. 43. モデルとは?に対する様々な答え ● DBA 「DBのテーブルのこと」 43
  44. 44. ● DBA 「DBのテーブルのこと」 ● サーバーサイドエンジニア 「テーブルに対応したオブジェクトのこと」 モデルとは?に対する様々な答え 44
  45. 45. モデルとは?に対する様々な答え ● DBA 「DBのテーブルのこと」 ● サーバーサイドエンジニア 「テーブルに対応したオブジェクトのこと」 ● 機械学習エンジニア 「数式のこと」 45
  46. 46. モデルとは? ● 「モデル」という言葉は文脈によって大きく違う使われ方をする ● 言葉の定義をしましょう
  47. 47. ● model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain ● モデル:問題解決のために、物事の特定の側面を抽象化したもの DDD文脈での定義 ざっくり意訳 47
  48. 48. モデルの区別 ● ドメインモデル: ● データモデル: 48
  49. 49. モデルの区別 ● ドメインモデル: ドメインの問題を解決するためのモデル ● データモデル: 49
  50. 50. モデルの区別 ● ドメインモデル: ドメインの問題を解決するためのモデル ● データモデル: データベースに何かを永続化するためのモデル 50
  51. 51. モデルの区別 ● ドメインモデル: ドメインの問題を解決するためのモデル ● データモデル: データベースに何かを永続化するためのモデル → これらは別のものであり、明確に区別する必要がある 51
  52. 52. ● モデル:問題解決のために、物事の特定の側面を抽象化したもの → 抽象化とは何でしょうか? DDD文脈での定義 52
  53. 53. 例:履歴書
  54. 54. 例:履歴書 現実には数多くの要素がある ・名前、経歴、志望理由 ・写真
  55. 55. 例:履歴書 現実には数多くの要素がある ・名前、経歴、志望理由 ・写真 ・筆跡、筆圧 ・紙質、折れ具合
  56. 56. 例:履歴書 現実には数多くの要素がある ・名前、経歴、志望理由 ・写真 ・筆跡、筆圧 ・紙質、折れ具合 ・履歴書のメーカー ・履歴書の値段 ・履歴書を書いた時の気持ち ・:
  57. 57. 現実世界の全ての要素をソフトウェアに落とし込むことは不可能
  58. 58. 現実世界の全ての要素をソフトウェアに落とし込むことは不可能 → 必要な要素はモデルに取り込みたい → 不要な要素はモデルに取り込みたくない
  59. 59. 現実世界の全ての要素をソフトウェアに落とし込むことは不可能 → 必要な要素はモデルに取り込みたい → 不要な要素はモデルに取り込みたくない この選択が「抽象化」
  60. 60. ● 良いモデルとは何か?
  61. 61. ● 良いモデルとは何か? わかりやすいモデル、現実に即しているモデル、拡張性のあるモデル…
  62. 62. ● 良いモデルとは何か? わかりやすいモデル、現実に即しているモデル、拡張性のあるモデル… →問題解決ができるモデル
  63. 63. ● 良いモデルとは何か? わかりやすいモデル、現実に即しているモデル、拡張性のあるモデル… →問題解決ができるモデル ● 良くないモデルとは何か?
  64. 64. ● 良いモデルとは何か? わかりやすいモデル、現実に即しているモデル、拡張性のあるモデル… →問題解決ができるモデル ● 良くないモデルとは何か? →問題解決ができないモデル ○ 現実に即していない ○ やりたいことができない
  65. 65. ● 中途採用における「採用進捗」 現実世界(ドメイン) モデル
  66. 66. ● 中途採用における「採用進捗」 現実世界(ドメイン) モデル
  67. 67. ● 中途採用における「採用進捗」 現実世界(ドメイン) モデル 書類選考の前に面談 があるのに・・・
  68. 68. ● 中途採用における「採用進捗」 現実世界(ドメイン) モデル 書類選考の前に面談 があるのに・・・ 面接は3次、4次もある のに・・・
  69. 69. ● 中途採用における「採用進捗」 現実世界(ドメイン) モデル 書類選考の前に面談 があるのに・・・ 面接は3次、4次もある のに・・・ 求人関係ない応募も 許可したい・・・
  70. 70. ● 中途採用における「採用進捗」 現実世界(ドメイン) モデル 書類選考の前に面談 があるのに・・・ 面接は3次、4次もある のに・・・ 求人関係ない応募も 許可したい・・・ 運用で カバー
  71. 71. 技術の敗北感がある
  72. 72. モデルが良くなくて問題解決できない
  73. 73. 運用でカバーできればまだマシ、 売れなければプロダクトがなくなる
  74. 74. ● もしも、このソフトウェアが
  75. 75. ● もしも、このソフトウェアが ● DDDの実装パターンを的確に使っている ● コードの可読性、拡張性が完璧 ● テストも完璧で、バグが全くでない
  76. 76. ● もしも、このソフトウェアが ● DDDの実装パターンを的確に使っている ● コードの可読性、拡張性が完璧 ● テストも完璧で、バグが全くでない  ものだったとしたら、高い価値を生み出せるか?
  77. 77. ● もしも、このソフトウェアが ● DDDの実装パターンを的確に使っている ● コードの可読性、拡張性が完璧 ● テストも完璧で、バグが全くでない  ものだったとしたら、高い価値を生み出せるか? → NO!!
  78. 78. ● モデルがイケてないと、 その後の実装がどんなに素晴らしくても良いソフトウェアにはならない
  79. 79. ● 良いモデルを作るにはどうすれば良いか?
  80. 80. ● 良いモデルを作るにはどうすれば良いか? →ドメインに詳しい人から知識を得る
  81. 81. ● 良いモデルを作るにはどうすれば良いか? →ドメインに詳しい人から知識を得る →運用した知見をモデルにフィードバックして改善する
  82. 82. ● 良いモデルを作るにはどうすれば良いか? →ドメインに詳しい人から知識を得る →運用した知見をモデルにフィードバックして改善する →モデルは最初から完成しない、改善していくもの  (DDDとして重要なスタンス)
  83. 83. ● モデルは最初から完成しない、改善していくもの モデル コード
  84. 84. ● モデルは最初から完成しない、改善していくもの モデル コード
  85. 85. ● コードとモデルが乖離すると… モデル コード
  86. 86. ● コードとモデルが乖離すると… ○ モデルの更新をコードに正しく反映できているかわからなくなる モデル コード
  87. 87. ● コードとモデルが乖離すると… ○ モデルの更新をコードに正しく反映できているかわからなくなる ○ モデルからコードを理解しにくくなる モデル コード
  88. 88. ● モデルの更新をコードに正しく反映できているかわからない ● コードからモデルを理解しにくい モデルとコードが乖離すると発生する問題
  89. 89. ● モデルの更新をコードに正しく反映できているかわからない →意図していない実装(=バグ)を産みやすくなる ● コードからモデルを理解しにくい モデルとコードが乖離すると発生する問題
  90. 90. ● モデルの更新をコードに正しく反映できているかわからない →意図していない実装(=バグ)を産みやすくなる ● コードからモデルを理解しにくい →ドメインに対する理解もできない →モデルは改善されない →ソフトウェアの価値を高めにくくなる モデルとコードが乖離すると発生する問題
  91. 91. ● コードとモデルが乖離すると問題が発生する ● モデルは継続的に改善したい 問題と対策
  92. 92. ● コードとモデルが乖離すると問題が発生する →モデルそのまま表現したコードとなるのが望ましい ● モデルは継続的に改善したい 問題と対策
  93. 93. ● コードとモデルが乖離すると問題が発生する →モデルそのまま表現したコードとなるのが望ましい →「オブジェクト」でモデルを表現する ● モデルは継続的に改善したい 問題と対策
  94. 94. ● コードとモデルが乖離すると問題が発生する →モデルそのまま表現したコードとなるのが望ましい →「オブジェクト」でモデルを表現する ● モデルは継続的に改善したい →コードにも継続的に反映しないと行けない →頻繁な変更に耐えうるには、拡張性の高い設計が必要 問題と対策
  95. 95. ● コードとモデルが乖離すると問題が発生する →モデルそのまま表現したコードとなるのが望ましい →「オブジェクト」でモデルを表現する ● モデルは継続的に改善したい →コードにも継続的に反映しないと行けない →頻繁な変更に耐えうるには、拡張性の高い設計が必要 →これはソフトウェアとしては非常に高い要求 問題と対策
  96. 96. ● コードとモデルが乖離すると問題が発生する →モデルそのまま表現したコードとなるのが望ましい →「オブジェクト」でモデルを表現する ● モデルは継続的に改善したい →コードにも継続的に反映しないと行けない →頻繁な変更に耐えうるには、拡張性の高い設計が必要 →これはソフトウェアとしては非常に高い要求 →そこで生まれたのがEntityやRepositoryなどのデザインパターン 問題と対策
  97. 97. ● 軽量DDD:DDDの実装パターンだけ取り入れること 軽量DDDとは
  98. 98. ● 軽量DDD:DDDの実装パターンだけ取り入れること ● 拡張性の高いベストプラクティスを取り入れる →それだけでも十分価値がある 軽量DDDとは
  99. 99. ● 軽量DDD:DDDの実装パターンだけ取り入れること ● 拡張性の高いベストプラクティスを取り入れる →それだけでも十分価値がある ● コード品質をあげると、ようやくモデリングする余地が生まれる と考えることもできる 軽量DDDとは
  100. 100. ● 軽量DDD:DDDの実装パターンだけ取り入れること ● 拡張性の高いベストプラクティスを取り入れる →それだけでも十分価値がある ● コード品質をあげると、ようやくモデリングする余地が生まれる と考えることもできる ● 何の問題もない、 そこからモデリングに踏み出しましょう 軽量DDDとは
  101. 101. DDDのアプローチ DDDのアプローチの全体像
  102. 102. DDDのアプローチ モデルがイケてないと、 実装がどんなに素晴らしくても良いソフトウェアにはならない
  103. 103. DDDのアプローチ モデルを継続的にソフトウェアに反映するために拡張性の高い設計をする
  104. 104. どうやってモデリングするのか 104
  105. 105. ドメインモデリングの方法 ● 一つに決まった方法はない ○ 体系化された手法の例 ■ リレーションシップ駆動要件分析(RDRA) ■ ユースケース駆動分析設計 ● シンプルな例をご紹介 ユースケース図 / ドメインモデル図によるモデリング ● タスク管理アプリケーションにおける事例で説明する 105
  106. 106. ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ 106
  107. 107. ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ 107
  108. 108. ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ ● 次に続くドメイン図作成の範囲も決める 今回のモデリングのス コープ 108
  109. 109. ● ユースケースの具体化・言語化 ○ ● ドメインモデル図作成作業の範囲を狭める ○ ユースケース図を作る必要性 109
  110. 110. ● ユースケースの具体化・言語化 ○ 具体化しないと、どのようなモデルを作ればいいかわからない ○ 「いち作業者として、自分のタスクを管理したい」のか 「管理者として、複数作業者のタスク状況を管理したい」のか それによって「タスク」のドメインモデルは違うものになる ● ドメインモデル図作成作業の範囲を狭める ○ ユースケース図を作る必要性 110
  111. 111. ● ユースケースの具体化・言語化 ○ 具体化しないと、どのようなモデルを作ればいいかわからない ○ 「いち作業者として、自分のタスクを管理したい」のか 「管理者として、複数作業者のタスク状況を管理したい」のか それによって「タスク」のドメインモデルは違うものになる ● ドメインモデル図作成作業の範囲を狭める ○ ドメインモデル図作成をしていると、いろんな要素が思い浮かんでくる ○ 範囲を限定して、限られた時間でまとまった成果を出せるようにする ユースケース図を作る必要性 111
  112. 112. ドメインモデル図 ● クラス図の簡易版 ● メソッド(振る舞い)は不要 ● 属性も代表的なものだけでOK ● 業務の「ルール・制約」(=ドメイン知識) を吹き出しで記述する ● 集約の範囲を明記する 112
  113. 113. 集約について ● 集約=「必ず守りたい強い整合性を持ったオブジェクトのまとまり」 ● 必ずまとめて取得して、まとめて更新する単位 ● 今回の発表では集約の検討が必要な事例は示せないが、 「このタイミングで集約設計する」ということを覚えておいてください 113
  114. 114. 実際のモデリング ● 最初はホワイトボードに殴り書きでOK 114
  115. 115. ドメインモデル図 115
  116. 116. どうやってコードに落とすか 116
  117. 117. まず、形から入る ● レイヤーを定義して「このレイヤにはこういうクラスを作る」というのを決める ● その決まりの上で、とりあえず動くものを書く ● 参考:新卒にも伝わるドメイン駆動設計のアーキテクチャ説明 117
  118. 118. ● 改善余地があるコードから入り、リファクタリングしていきます 説明の流れ 118
  119. 119. ● この段階では属性の定義のみ、ドメイン知識は持っていない Taskクラス 119
  120. 120. TaskApplicationSericeクラス -タスクを登録する ● ApplicationServiceクラスにタスク登録時の処理を書く 120
  121. 121. ● 延期時の処理も同様 TaskApplicationSericeクラス -タスクを延期する 121
  122. 122. このコードの問題点 ● 不整合なデータをいくらでも作れる ● 仕様を追いかけるのに、複数クラスをコード参照から追っていくしかない 122
  123. 123. ドメインモデル図の見直し ● ドメインモデル図の吹き出しの知識はどのクラスに書かれているか? 123
  124. 124. TaskApplicationSericeクラス -タスクを登録する タスクは未完了状態で作成 される 124
  125. 125. TaskApplicationSericeクラス -タスクを延期する タスクは3回だけ、 1日ずつ延期することができる。 125
  126. 126. ● ドメインモデル図の知識がApplication層のクラスに書かれている タスクは未完了状態で作成 される タスクは3回だけ、 1日ずつ延期することができる。 126
  127. 127. ● ドメインモデル図の知識をDomain層のクラス、 特に吹き出しが書かれたオブジェクトに委譲する タスクは未完了状態で作成 される タスクは3回だけ、 1日ずつ延期することができる。 127
  128. 128. ● 修正前のクラスを再度確認 ● このクラスに、吹き出しの知識を委譲する Taskクラス -Before 128
  129. 129. Taskクラス -After (1/3) コンストラクタ ● コンストラクタにタスク作成時の知識を移譲 タスクは未完了状態で作成 される 129
  130. 130. Taskクラス -After (2/3) 延期メソッド ● 延期メソッドに延期時の知識を移譲 タスクは3回だけ、 1日ずつ延期することができる。 130
  131. 131. Taskクラス -After (3/3) Setter ● Setterがなくなっているので、公開しているメソッド以外で操作できない 131
  132. 132. シンプルになったApplicationServiceクラス ● ユースケース記述レベルの抽象度の高いコードのみ残る 132
  133. 133. この設計のメリット(1/3) ● 不整合なデータを作れないように強制できる ○ Setter非公開にしたので不整合な値をセットできない コンパイルエラーになる 133
  134. 134. この設計のメリット(2/3) ● 他のルールで生成・更新 されないことが確実になっている ● 1クラスに吹き出しの知識が 凝縮されている →「このクラスだけ見れば良い」 という大きな安心感を得られる 134
  135. 135. この設計のメリット(3/3) ● レイヤーによって書くべきことが決まっている →コード規約の様に定めて、  実装やレビューの時に使える ● 「俺の考えた最強の設計」同士が戦わなくて済む 135
  136. 136. どうやって現場で実践するか 136
  137. 137. ● お手本コードを作る ○ ApplicationService、Entity、Repository・・・ ● お手本に倣ってコードを書くようにチーム展開する ○ この段階では軽量DDDでも全然OK ● 「あれ、ドメイン層には何を書くべきなんだっけ?」 となったら、ドメインモデリングしてみる ● ドメインモデル図を元にリファクタリングしていく DDD導入の進め方 137
  138. 138. ● 「原理を理解して実践」より、 「お手本を元に展開」の方が圧倒的に難易度が低いため ● ● なぜお手本コード展開から入るのか 138
  139. 139. ● 「原理を理解して実践」より、 「お手本を元に展開」の方が圧倒的に難易度が低いため ● ドメイン層に何を書くべきか?という疑問を持った方が モデリングの必要性を感じやすいため ● なぜお手本コード展開から入るのか 139
  140. 140. なぜお手本コード展開から入るのか ● 「原理を理解して実践」より、 「お手本を元に展開」の方が圧倒的に難易度が低いため ● ドメイン層に何を書くべきか?という疑問を持った方が モデリングの必要性を感じやすいため ● 「どういうコードに落としこまれるのか」が イメージできてからの方が、ドメインモデリングしやすいため 140
  141. 141. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない コーディング モデリング 141
  142. 142. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない コーディング モデリング 142
  143. 143. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ● 両方交互に経験値をためながら上達していくしかない コーディング モデリング 143
  144. 144. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ● 両方交互に経験値をためながら上達していくしかない ● 結局、このサイクルのどちらから入るか、という違いだけ コーディング モデリング 144
  145. 145. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ● 両方交互に経験値をためながら上達していくしかない ● 結局、このサイクルのどちらから入るか、という違いだけ ● コーディングと、モデリングを意識的に両方少しずつやってみるのが良い コーディング モデリング 145
  146. 146. まとめ ● DDDでは、「モデルを継続的に改善」「モデルの更新をソフトウェアに反映」のアプロー チでソフトウェアの価値を高める ● モデルの更新を反映しやすいように、モデルをそのまま表現する その際にオブジェクト指向の手法を利用する ● DDD戦術設計パターンは、保守性の高い設計のベストプラクティス ● 設計パターンの適用(軽量DDD)と、モデリングを両方使うと、 ソフトウェアの価値を高められる ● 実装と、モデリングを少しずつ着手してみよう 146
  147. 147. 他の章の紹介 147
  148. 148. 他の章の紹介 148
  149. 149. 他の章にも興味を持っていただけた方は 149 「ドメイン駆動設計 モデリング/実装ガイド」 boothにて販売中
  150. 150. 質問箱で質問募集しています ● 質問いただければ回答します ● https://peing.net/ja/little_hands ● 「質問箱 little_hands」で検索 150
  151. 151. ご静聴ありがとうございました 151
  152. 152. sli.do回答タイム 152
  153. 153. ご静聴ありがとうございました 153

×