ドメイン駆動設計 モデリング_実装入門勉强会_2020.3.8
?
34 likes?7,941 views
ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 発売記念に、本書の1,2章の内容を中心にDDDの概要について解説する勉强会です。
ドメイン駆動設計 モデリング_実装入門勉强会_2020.3.8
- 2. 自己紹介 ● 松岡 幸一郎 (@little_hand_s) ● DDD community jp主催 ● DDD周りの話をするブログ書いてます ● WEB+DB PRESS 2019年10月号 特集「体験ドメイン駆動設計」執筆 2
- 3. 本日の趣旨 3 ● 「ドメイン駆動設計 モデリング/実装ガイド」 技術書典8向けに執筆 ● 発売記念として、本書の一部内容+αを オンライン講義形式で解説します
- 4. ● オンラインで既存のオフライン勉强会をどの程度代替できるか、 の検証としての試み オンライン勉强会というチャレンジ オフライン勉强会 ● 前に立って発表 ● Twitterのハッシュタグツイート ● Sli.doによる質疑応答 ● 登壇後の個別質問 4 オンライン勉强会 ● ● ● ●
- 5. ● オンラインで既存のオフライン勉强会をどの程度代替できるか、 の検証としての試み オンライン勉强会というチャレンジ オフライン勉强会 ● 前に立って発表 ● Twitterのハッシュタグツイート ● Sli.doによる質疑応答 ● 登壇後の個別質問 5 オンライン勉强会 ● YouTube Liveによる配信 ● ● ●
- 6. ● オンラインで既存のオフライン勉强会をどの程度代替できるか、 の検証としての試み オンライン勉强会というチャレンジ オフライン勉强会 ● 前に立って発表 ● Twitterのハッシュタグツイート ● Sli.doによる質疑応答 ● 登壇後の個別質問 6 オンライン勉强会 ● YouTube Liveによる配信 ● Twitterのハッシュタグツイート ● Sli.doによる質疑応答 ●
- 7. ● オンラインで既存のオフライン勉强会をどの程度代替できるか、 の検証としての試み オンライン勉强会というチャレンジ オフライン勉强会 ● 前に立って発表 ● Twitterのハッシュタグツイート ● Sli.doによる質疑応答 ● 登壇後の個別質問 7 オンライン勉强会 ● YouTube Liveによる配信 ● Twitterのハッシュタグツイート ● Sli.doによる質疑応答 ● YouTube Liveのチャットによる質問 やりとり
- 8. 質問受け付けます ● sli.doで質問受け付けます ○ https://app.sli.do/event/imvxc56h にアクセス ○ 質問を追加 or 既存の質問に投票 8
- 9. 質問受け付けます ● sli.doで質問受け付けます ○ https://app.sli.do/event/imvxc56h にアクセス ○ 質問を追加 or 既存の質問に投票 ● ツイートは通常のイベントのようにお願いします ○ Twitterハッシュタグは #ddd_guide ○ YouTube Live上のコメントもOK 9
- 11. スポンサーご紹介 11
- 12. GOLD? スポンサー
- 15. 今日話す内容 15
- 16. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル 話す内容 16
- 17. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル ● モデリングから実装まで ○ ドメインモデリングの方法 ○ ドメインモデルを実装に落とす ○ ライブコーディング 話す内容 17
- 18. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル ● モデリングから実装まで ○ ドメインモデリングの方法 ○ ドメインモデルを実装に落とす ○ ライブコーディング ● プロジェクトへの導入方法のススメ 話す内容 18
- 19. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル ● モデリングから実装まで ○ ドメインモデリングの方法 ○ ドメインモデルを実装に落とす ○ ライブコーディング ● プロジェクトへの導入方法のススメ ● 「ドメイン駆動設計 モデリング/実装ガイド」他の章の紹介 話す内容 19
- 20. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル ● モデリングから実装まで ○ ドメインモデリングの方法 ○ ドメインモデルを実装に落とす ○ ライブコーディング ● プロジェクトへの導入方法のススメ ● 「ドメイン駆動設計 モデリング/実装ガイド」他の章の紹介 話す内容 20 1章より
- 21. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル ● モデリングから実装まで ○ ドメインモデリングの方法 ○ ドメインモデルを実装に落とす ○ ライブコーディング ● プロジェクトへの導入方法のススメ ● 「ドメイン駆動設計 モデリング/実装ガイド」他の章の紹介 話す内容 21 1章より 2章より
- 22. ● DDD概要 ○ DDDとは ○ モデルとは ○ 良いモデル、良くないモデル ● モデリングから実装まで ○ ドメインモデリングの方法 ○ ドメインモデルを実装に落とす ○ ライブコーディング ● プロジェクトへの導入方法のススメ ● 「ドメイン駆動設計 モデリング/実装ガイド」他の章の紹介 話す内容 22 1章より 2章より 3~11章
- 23. 資料公開 ● サンプルコード ○ GitHubにて公開中 ● 資料 ○ こちらにて公開中 23
- 24. 今日のゴール 24
- 27. 今日のゴール ● DDDの概要、開発の流れを理解する ● DDD、そんなに難しくないと思えるようになる ● 顿顿顿についてもっと知りたくなる
- 28. DDDとは 28
- 29. DDDとは ● DDDとは
- 34. ● DDD： DomainDrivenDesign(ドメイン駆動設計)の略 ● DDD Referenceより "多くのプロジェクトは、モデリングを行っても 最終的に大きな利益を得られないまま終わります。 DDDは、モデリングから劇的な利益を得られたプロジェクトから、 成功するパターンを抽出します。”
- 36. ● DDD： DomainDrivenDesign(ドメイン駆動設計)の略 ● DDD Referenceより "多くのプロジェクトは、モデリングを行っても 最終的に大きな利益を得られないまま終わります。 DDDは、モデリングから劇的な利益を得られたプロジェクトから、 成功するパターンを抽出します。”
- 38. あれ？
- 45. モデルとは？に対する様々な答え ● DBA 「DBのテーブルのこと」 ● サーバーサイドエンジニア 「テーブルに対応したオブジェクトのこと」 ● 機械学習エンジニア 「数式のこと」 45
- 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
- 51. モデルの区別 ● ドメインモデル： ドメインの問題を解決するためのモデル ● データモデル： データベースに何かを永続化するためのモデル → これらは別のものであり、明確に区別する必要がある 51
- 53. 例：履歴书
- 60. ● 良いモデルとは何か？
- 64. ● 良いモデルとは何か？ わかりやすいモデル、現実に即しているモデル、拡張性のあるモデル… →問題解決ができるモデル ● 良くないモデルとは何か？ →問題解決ができないモデル ○ 現実に即していない ○ やりたいことができない
- 71. 技术の败北感がある
- 74. ● もしも、このソフトウェアが
- 75. ● もしも、このソフトウェアが ● DDDの実装パターンを的確に使っている ● コードの可読性、拡張性が完璧 ● テストも完璧で、バグが全くでない
- 76. ● もしも、このソフトウェアが ● DDDの実装パターンを的確に使っている ● コードの可読性、拡張性が完璧 ● テストも完璧で、バグが全くでない ものだったとしたら、高い価値を生み出せるか？
- 77. ● もしも、このソフトウェアが ● DDDの実装パターンを的確に使っている ● コードの可読性、拡張性が完璧 ● テストも完璧で、バグが全くでない ものだったとしたら、高い価値を生み出せるか？ → NO！！
- 87. ● コードとモデルが乖離すると… ○ モデルの更新をコードに正しく反映できているかわからなくなる ○ モデルからコードを理解しにくくなる モデル コード
- 99. ● 軽量DDD：DDDの実装パターンだけ取り入れること ● 拡張性の高いベストプラクティスを取り入れる →それだけでも十分価値がある ● コード品質をあげると、ようやくモデリングする余地が生まれる と考えることもできる 軽量DDDとは
- 100. ● 軽量DDD：DDDの実装パターンだけ取り入れること ● 拡張性の高いベストプラクティスを取り入れる →それだけでも十分価値がある ● コード品質をあげると、ようやくモデリングする余地が生まれる と考えることもできる ● 何の問題もない、 そこからモデリングに踏み出しましょう 軽量DDDとは
- 104. どうやってモデリングするのか 104
- 105. ドメインモデリングの方法 ● 一つに決まった方法はない ○ 体系化された手法の例 ■ リレーションシップ駆動要件分析(RDRA) ■ ユースケース駆動分析設計 ● シンプルな例をご紹介 ユースケース図 / ドメインモデル図によるモデリング ● タスク管理アプリケーションにおける事例で説明する 105
- 108. ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ ● 次に続くドメイン図作成の範囲も決める 今回のモデリングのス コープ 108
- 110. ● ユースケースの具体化?言語化 ○ 具体化しないと、どのようなモデルを作ればいいかわからない ○ 「いち作業者として、自分のタスクを管理したい」のか 「管理者として、複数作業者のタスク状況を管理したい」のか それによって「タスク」のドメインモデルは違うものになる ● ドメインモデル図作成作業の範囲を狭める ○ ユースケース図を作る必要性 110
- 111. ● ユースケースの具体化?言語化 ○ 具体化しないと、どのようなモデルを作ればいいかわからない ○ 「いち作業者として、自分のタスクを管理したい」のか 「管理者として、複数作業者のタスク状況を管理したい」のか それによって「タスク」のドメインモデルは違うものになる ● ドメインモデル図作成作業の範囲を狭める ○ ドメインモデル図作成をしていると、いろんな要素が思い浮かんでくる ○ 範囲を限定して、限られた時間でまとまった成果を出せるようにする ユースケース図を作る必要性 111
- 112. ドメインモデル図 ● クラス図の簡易版 ● メソッド(振る舞い)は不要 ● 属性も代表的なものだけでOK ● 業務の「ルール?制約」(=ドメイン知識) を吹き出しで記述する ● 集約の範囲を明記する 112
- 113. 集約について ● 集約＝「必ず守りたい強い整合性を持ったオブジェクトのまとまり」 ● 必ずまとめて取得して、まとめて更新する単位 ● 今回の発表では集約の検討が必要な事例は示せないが、 「このタイミングで集約設計する」ということを覚えておいてください 113
- 115. ドメインモデル図 115
- 116. どうやってコードに落とすか 116
- 117. まず、形から入る ● レイヤーを定義して「このレイヤにはこういうクラスを作る」というのを決める ● その決まりの上で、とりあえず動くものを書く ● 参考：新卒にも伝わるドメイン駆動設計のアーキテクチャ説明 117
- 127. ● ドメインモデル図の知識をDomain層のクラス、 特に吹き出しが書かれたオブジェクトに委譲する タスクは未完了状態で作成 される タスクは3回だけ、 1日ずつ延期することができる。 127
- 128. ● 修正前のクラスを再度確認 ● このクラスに、吹き出しの知識を委譲する Taskクラス -Before 128
- 129. Taskクラス -After (1/3) コンストラクタ ● コンストラクタにタスク作成時の知識を移譲 タスクは未完了状態で作成 される 129
- 130. Taskクラス -After (2/3) 延期メソッド ● 延期メソッドに延期時の知識を移譲 タスクは3回だけ、 1日ずつ延期することができる。 130
- 131. Taskクラス -After (3/3) Setter ● Setterがなくなっているので、公開しているメソッド以外で操作できない 131
- 135. この設計のメリット(3/3) ● レイヤーによって書くべきことが決まっている →コード規約の様に定めて、 実装やレビューの時に使える ● 「俺の考えた最強の設計」同士が戦わなくて済む 135
- 136. どうやって現場で実践するか 136
- 137. ● お手本コードを作る ○ ApplicationService、Entity、Repository??? ● お手本に倣ってコードを書くようにチーム展開する ○ この段階では軽量DDDでも全然OK ● 「あれ、ドメイン層には何を書くべきなんだっけ？」 となったら、ドメインモデリングしてみる ● ドメインモデル図を元にリファクタリングしていく DDD導入の進め方 137
- 140. なぜお手本コード展開から入るのか ● 「原理を理解して実践」より、 「お手本を元に展開」の方が圧倒的に難易度が低いため ● ドメイン層に何を書くべきか？という疑問を持った方が モデリングの必要性を感じやすいため ● 「どういうコードに落としこまれるのか」が イメージできてからの方が、ドメインモデリングしやすいため 140
- 143. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ● 両方交互に経験値をためながら上達していくしかない コーディング モデリング 143
- 144. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ● 両方交互に経験値をためながら上達していくしかない ● 結局、このサイクルのどちらから入るか、という違いだけ コーディング モデリング 144
- 145. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ● 両方交互に経験値をためながら上達していくしかない ● 結局、このサイクルのどちらから入るか、という違いだけ ● コーディングと、モデリングを意識的に両方少しずつやってみるのが良い コーディング モデリング 145
- 146. まとめ ● DDDでは、「モデルを継続的に改善」「モデルの更新をソフトウェアに反映」のアプロー チでソフトウェアの価値を高める ● モデルの更新を反映しやすいように、モデルをそのまま表現する その際にオブジェクト指向の手法を利用する ● DDD戦術設計パターンは、保守性の高い設計のベストプラクティス ● 設計パターンの適用(軽量DDD)と、モデリングを両方使うと、 ソフトウェアの価値を高められる ● 実装と、モデリングを少しずつ着手してみよう 146
- 147. 他の章の紹介 147
- 148. 他の章の紹介 148
- 150. 質問箱で質問募集しています ● 質問いただければ回答します ● https://peing.net/ja/little_hands ● 「質問箱 little_hands」で検索 150
- 151. ご静聴ありがとうございました 151
- 152. sli.do回答タイム 152
- 153. ご静聴ありがとうございました 153