Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DDD: ドメイン駆動設計 入門 ~はじめの一歩~

t2-kob
June 25, 2021

DDD: ドメイン駆動設計 入門 ~はじめの一歩~

社内でDDD勉強会をした際の資料です。
資料のみだと理解がやや難しい構成ですので、ぜひ動画(↓) とセットでご参照ください。

https://www.youtube.com/watch?v=03lDC8s0S5U

t2-kob

June 25, 2021
Tweet

More Decks by t2-kob

Other Decks in Programming

Transcript

  1. 今日のゴール • 第1部 ◦ DDDについてふんわりその目的を理解できている • 第2部 ◦ DDDにおけるアーキテクチャについてふんわりその目的を理解できている ◦

    クリーンアーキテクチャ(CA)についてふんわりその目的を理解できている ◦ DDDとクリーンアーキテクチャの近くて遠い関係性をふんわり理解できている 2
  2. やること・やらないこと やること • DDD の全体像の説明 • CA の全体像の説明 • DDD

    と CA の関係性の 説明 やらないこと • 細かな実装方法の説明 3
  3. DDD によくある勘違い - 正しくは Q.Repository, Aggregate, Entity などを 使えば DDD

    なんだよね? A.ちがうよ! それは具体的な実装手法のひとつでしかないよ! 19
  4. 27

  5. 「ドメイン」=「人や物・情報が活動する領域」 世界 銀行 飲食業 自転車 自動車 宇宙開発 カメラ クラファン ドメイン

    「クラウドファンディングに関係する 人や物・情報などが活動する領域」 と定める。 40
  6. 「ドメイン」=「人や物・情報が活動する領域」 世界 銀行 飲食業 自転車 自動車 宇宙開発 カメラ クラファン ドメイン

    「クラウドファンディングに関係する 人や物・情報などが活動する領域」 と定める。 41  境界線を切ることで、  「私たちが戦うべき領域」を明らかにする。  このため狭義の「ドメイン」は、  システム化の対象となる領域と言われることもある。
  7. 42

  8. 51

  9. DDD は具体的にどんなことをする? ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 •

    全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 53 再掲 何で一緒にやるの? 何で共通の言葉なの? 図がコミュニケーションと何故 関係するの? なんでそんなやり方をするの? どうやって探すの?
  10. DDD は具体的にどんなことをする? ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 •

    全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 54 再掲 何で一緒にやるの? 何で共通の言葉なの? モデルがコミュニケーションと何 故関係するの? なんでそんなやり方をするの? どうやって探すの? きになることだらけ
  11. 世界 クラファンドメイン プロジェク ト運営ドメ イン プロジェク ト審査ドメ イン 振り込み ドメイン

    プロジェク ト準備ドメ イン どこが価値の源泉となるのかを「みんな」で考える ドメインはこんな 感じだ!! 59
  12. 世界 クラファンドメイン プロジェク ト運営ドメ イン プロジェク ト審査ドメ イン 振り込み ドメイン

    プロジェク ト準備ドメ イン どこが価値の源泉となるのかを「みんな」で考える ここが最も大切な 「価値の源泉」 になる領域だ!! 60
  13. 75

  14. 76

  15. 79

  16. DDD は具体的にどんなことをする? ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 •

    全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 82 再掲 「みんな」に共通の言葉でドメインモデルを作る (イメージ)  プロジェク ト 支援者 支援 実行者
  17. 95

  18. 97

  19. 98

  20. 99

  21. 100

  22. 101

  23. 102

  24. 103

  25. 106

  26. 107

  27. ドメインや文脈ごとに「言葉」を特化させる 110 「プロジェクト」 資金を調 達したい 人 キュレー ターさん 支援してく れる人

    「プロジェクト」 資金を調 達したい 人 キュレー ターさん 支援してく れる人 「プロジェクト」 「プロジェクト」 こう↑ならないように・・・
  28. ドメインや文脈ごとに「言葉」を特化させる 111 「プロジェクト」 資金を調 達したい 人 キュレー ターさん 支援してく れる人

    「プロジェクト」 資金を調 達したい 人 キュレー ターさん 支援してく れる人 「プロジェクト」 「プロジェクト」 同じ言葉であっても、ドメインや文脈が違えば違う概念 。 それをドメインモデルをそれぞれ分離する ことで表す。 同じ言葉が、異なる概念としてそれぞれ成長していく。
  29. 113

  30. DDD ではこの「伝言ゲーム」をどう解決する? ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 •

    全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 122 ドメインモデルをすべての中心に置き、 業務に関わる概念だけで会話できるようにし、 その概念とコードを1:1で対応させる。
  31. 127

  32. A.ちがうよ!それは具体的な実装手法のひとつでしか ないよ! 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 最速で変化に追従できるよう「みんな」で変化し続けたい。 だからこそ、変化し続けられるような実装手段を取る。 それが Value Object や Repository,

    疎結合なアーキテクチャ などの正体。 あくまでも DDD の目的を達成するための手段として種々の実装方法がある。 つまり「DDD的(OOP的)な実装方法を適用している」からといって、 それが「DDD である」ことにはならない。要注意!! 133
  33. A.ちがうよ!それは具体的な実装手法のひとつでしか ないよ! 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 最速で変化に追従できるよう「みんな」で変化し続けたい。 だからこそ、変化し続けられるような実装手段を取る。 それが Value Object や Repository,

    疎結合なアーキテクチャ などの正体。 あくまでも DDD の目的を達成するための手段として種々の実装方法がある。 つまり「DDD的(OOP的)な実装方法を適用している」からといって、 それが「DDD である」ことにはならない。要注意!! 134 が... この辺りの目的や関係性を理解しないまま 実装面だけを導入しようとして失敗してしまうのが DDD 導入失敗の黄金パターン。 DDD の主眼は「ドメイン全体の設計」 にあることに注意!
  34. 135

  35. 「ドメイン」が「設計」を「駆動」する? 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア

    ビジネス エキス パート 141 • エンジニアとビジネスサイド の人たちが一緒に、
  36. 「ドメイン」が「設計」を「駆動」する? 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア

    ビジネス エキス パート 142 • エンジニアとビジネスサイド の人たちが一緒に、 • 私たちのビジネスの中で最も価値を生む 全力投球すべき部分 を見つけて、 • 全員に共通の言葉 を使い、そこに含まれる 概念の関係性を分析・図示化 • その図をコミュニケーションから実装まで の全ての中心に置く。   プロジェ クト 支援者 支援 実行者
  37. 「ドメイン」が「設計」を「駆動」する? 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア

    ビジネス エキス パート 144 外部環境の変化を 皮切りに 生まれた課題を解決でき るよう、ドメインモデルをみ んなで変更   プロジェク ト 支援者 支援 実行者 寄付 New!
  38. 「ドメイン」が「設計」を「駆動」する? 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア

    ビジネス エキス パート 145 外部環境の変化を 皮切りに それをプログラムに 反映させる 生まれた課題を解決でき るよう、ドメインモデルをみ んなで変更
  39. 「ドメイン」が「設計」を「駆動」する? 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア

    ビジネス エキス パート 146 外部環境の変化を 皮切りに それをプログラムに 反映させる プログラムを契機にモ デルを深化させる 生まれた課題を解決でき るよう、ドメインモデルをみ んなで変更
  40. 「ドメイン」が「設計」を「駆動」する? 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア

    ビジネス エキス パート 147 外部環境の変化を 皮切りに それをプログラムに 反映させる プログラムを契機にモ デルを深化させる それがビジネス戦略に まで繋がっていく 生まれた課題を解決でき るよう、ドメインモデルをみ んなで変更
  41. 「ドメイン」が「設計」を「駆動」する? 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア

    ビジネス エキス パート 148 外部環境の変化を 皮切りに それをプログラムに 反映させる プログラムを契機にモ デルを深化させる それがビジネス戦略に まで繋がっていく 生まれた課題を解決でき るよう、ドメインモデルをみ んなで変更 「駆動」の一例
  42. DDD の用語に置き換えると? ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 •

    全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 155 コアドメイン ユビキタス言語 ドメインモデル モデル駆動設計・ 各種実装技法 蒸留・ブレイクスルー・ リファクタリング ドメイン・コンテキスト
  43. 157

  44. A.ちがうよ!それは具体的な実装手法のひとつでしか ないよ! 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 最速で変化に追従できるよう「みんな」で変化し続けたい。 だからこそ、変化し続けられるような実装手段を取る。 それが Value Object や Repository,

    疎結合なアーキテクチャ などの正体。 あくまでも DDD の目的を達成するための手段として種々の実装方法がある。 つまり「DDD的(OOP的)な実装方法を適用している」からといって、 それが「DDD である」ことにはならない。要注意!! 161
  45. A.ちがうよ!それは具体的な実装手法のひとつでしか ないよ! 162 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 最速で変化に追従できるよう「みんな」で変化し続けたい。 だからこそ、変化し続けられるような実装手段を取る。 それが Value Object や

    Repository, 疎結合なアーキテクチャ などの正体。 あくまでも DDD の目的を達成するための手段として種々の実装方法がある。 つまり「DDD的(OOP的)な実装方法を適用している」からといって、 それが「DDD である」ことにはならない。要注意!!
  46. 166

  47. こういう言葉、聞いたことありませんか? • 「DBがこうだから変更できないんだよなあ」 • 「ここを直したいけど ActiveRecord と相性悪いんだよなあ」 • 「外部から取り込む CSV

    の形式が変わったからロジック総崩れだ」 • 「値が変更されたからモデルを.save()しよう」 179 外界からビジネスルールに不要なものを持ち込む?
  48. こういう言葉、聞いたことありませんか? • 「DBがこうだから変更できないんだよなあ」 • 「ここを直したいけど ActiveRecord と相性悪いんだよなあ」 • 「外部から取り込む CSV

    の形式が変わったからロジック総崩れだ」 • 「値が変更されたからモデルを.save()しよう」 180 外界からビジネスルールに不要なものを持ち込む? これらは本来、業務ロジック/ビジネスルールとは全く関係がない。 例えば「プロジェクト」を達成するために必要なルールである、 「期間中に目標金額を達成する」には DB が登場する余地はない筈。
  49. こういう言葉、聞いたことありませんか? • 「DBがこうだから変更できないんだよなあ」 • 「ここを直したいけど ActiveRecord と相性悪いんだよなあ」 • 「外部から取り込む CSV

    の形式が変わったからロジック総崩れだ」 • 「値が変更されたからモデルを.save()しよう」 181 外界からビジネスルールに不要なものを持ち込む? こういう言葉が出てくるという事は、私たちの業務ロジックやビジネ スルールの中に、こっそり本質と関係のない外界の何かによる影響が 入り込んでしまっていることを意味する。 そしてそれは少しずつ根を張り絡み合い、変更を困難にしていく。
  50. こういう言葉、聞いたことありませんか? • 「DBがこうだから変更できないんだよなあ」 • 「ここを直したいけど ActiveRecord と相性悪いんだよなあ」 • 「外部から取り込む CSV

    の形式が変わったからロジック総崩れだ」 • 「値が変更されたからモデルを.save()しよう」 182 外界からビジネスルールに不要なものを持ち込む? こういう言葉が出てくるという事は、私たちの業務ロジックやビジネ スルールの中に、こっそり本質と関係のない外界の何かによる影響が 入り込んでしまっていることを意味する。 そしてそれは少しずつ根を張り絡み合い、変更を困難にしていく。 だから、鎖国する
  51. こういう言葉、聞いたことありませんか? • 「DBがこうだから変更できないんだよなあ」 • 「ここを直したいけど ActiveRecord と相性悪いんだよなあ」 • 「外部から取り込む CSV

    の形式が変わったからロジック総崩れだ」 • 「値が変更されたからモデルを.save()しよう」 183 外界からビジネスルールに不要なものを持ち込む? こういう言葉が出てくるという事は、私たちの業務ロジックやビジネ スルールの中に、こっそり本質と関係のない外界の何かによる影響が 入り込んでしまっていることを意味する。 そしてそれは少しずつ根を張り絡み合い、変更を困難にしていく。 だから、鎖国する 具体的には、依存の関係性を円の外から内に向けた1方向に制限したり、 Dependency Injection や Repository パターン を採用するなどして疎結合化。 このように国内のドメイン特化のビジネスルールと、外界(画面・DB・ライブラリなど) が 交わらないようにすることで平和を守っている。
  52. 187

  53. つながる DDD とクリーンアーキテクチャ 192 DDD は・・・ ドメインモデルをコミュニケーショ ンから実装までのすべての中心に置 き、変化に強くする。 クリーンアーキテクチャは・・・

    ドメインモデルを自分たちの世界の 中心において守り、外部からの影響 を廃すことで、変化に強くする。 変化に強くするという目的は同じ。 だが、目線が異なる。
  54. つながる DDD とクリーンアーキテクチャ 193 DDD は・・・ ドメインモデルをコミュニケーショ ンから実装までのすべての中心に置 き、変化に強くする。 クリーンアーキテクチャは・・・

    ドメインモデルを自分たちの世界の 中心において守り、外部からの影響 を廃すことで、変化に強くする。 ドメインだけでなく、そのプロセスなど 関わるもの全てが対象 あくまでも自分のドメインモデルをど う実装するかが主軸
  55. • DDD とクリーンアーキテクチャは目的が似ている。 • しかし、そもそも目線が全く異なる。 ◦ DDD がドメインだけでなくプロセスなどまで関心を持つ事に対し、 ◦ クリーンアーキテクチャの興味範囲はあくまでもアーキテクチャレベルでしか無い。

    ◦ クリーンアーキテクチャはあくまでも「手段」 である。 • つまり、そもそも比較する/できるものではない。 • クリーンアーキテクチャを採用するだけでは DDD ではないことに注意が必要。 195 まとめ ※ クリーンアーキテクチャと鎖国の話については手前味噌ですが Clean Architecture の勘所は『鎖国』だ。 を参照ください。 

  56. 196