DDD‗20250716_traP×DMM

Transcript

1. © DMM © DMM CONFIDENTIAL ドメイン駆動設計 をはじめよう 0716 - traP LT 松本響輝 2025-07-16
2. © DMM CONFIDENTAL はじめに
3. © DMM このスライドの目的 • ドメイン駆動設計を実践しようと思えるようになること • 「DDD？なにそれ？こわい...」な状態から「DDD？ちょっとわかる」に • それぞれの環境にあった方法で実践を • ドメインモデリング会を開いてみる • ドメイン駆動設計勉強会を開いてみる • あえて「ドメイン駆動設計」という単語を使わずに普及させてく • など 3
4. © DMM 今日やらないこと • 実装やコード例を踏まえた詳細の解説 • よく言われる「値オブジェクト」や「集約」などのパターンの説明 4 つまり、実装に踏み込んだ話はしないです！
5. © DMM 目次 • 第1部 ドメイン駆動設計のなりたち • 第2部 事業の “中核” を分析しよう • 第3部 “同じ言葉” を使おう • 第4部 “区切られた文脈” で分解しよう 5
6. © DMM CONFIDENTAL 第1部 ドメイン駆動設計のなりたち DDDが生まれた当時の課題を知ろう
7. © DMM ドメイン駆動設計とは 「より良いソフトウェアを開発するために、ソフトウェアが対象としているもの （ドメイン）を中心に考えて開発する手法の一種」 （数学のような厳密な定義はないはずで、「これはDDDだ！」とか「これは DDDでない！」と区別してもしなくてもよいと思います） 7
8. © DMM ドメイン駆動設計の分類 大きく２つに分かれます • 戦略的設計 ◦ 業務領域を分類したり、同じ言葉（ユビキタス言語）を使ったり、ドメイン駆動設計 の根幹となる思想や指針に関すること • 戦術的設計 ◦ 戦略的設計を実現するにあたって、コードに落とし込む際の実装テクニックなど のこと 8
9. © DMM 戦略と戦術 9 戦略 大局的にどう動くか 戦術 局所的にどう動くか • がんがんいこうぜ • いのちだいじに • じゅもんつかうな 1. はじまりの町 2. ダンジョン 3. ラスボス
10. © DMM ドメイン駆動設計の分類 大きく２つに分かれます • 戦略的設計 ◦ 業務領域を分類したり、同じ言葉（ユビキタス言語）を使ったり、ドメイン駆動設 計の根幹となる思想や指針に関すること • 戦術的設計 ◦ 戦略的設計を実現するにあたって、コードに落とし込む際の実装テクニックなど のこと 10 この講義では戦略的設計を扱っていきます
11. © DMM ドメイン駆動設計のなりたち • Eric Evans が 2003 年に「Domain-Driven Design」を出版 11 画像: https://x.com/ericevans0
12. © DMM 2003年頃の開発 12 1999年: Extreme Programming 出版（いわゆるXP）
13. © DMM 2003年頃の開発 13 1999年: Extreme Programming 出版（いわゆるXP） 2001年: アジャイルソフトウェア開発宣言
14. © DMM 2003年頃の開発 14 1999年: Extreme Programming 出版（いわゆるXP） 2001年: アジャイルソフトウェア開発宣言 2002年: Patterns of Enterprise Application Architecture(PoEAA)出版 ←これに「値オブジェクト」「ドメイン モデル」などが！
15. © DMM 2003年頃の開発 15 1999年: Extreme Programming 出版（いわゆるXP） 2001年: アジャイルソフトウェア開発宣言 2002年: Patterns of Enterprise Application Architecture(PoEAA)出版 2004年: Ruby on Rails 公開
16. © DMM 2003年頃の開発 • 基本的にウォーターフォールのような体制が主流 • 設計屋さん(アーキテクト)とコーディング屋さん(プログラマー)が分かれていた 16
17. © DMM 2003年頃の開発 • 基本的にウォーターフォールのような体制が主流 • 設計屋さん(アーキテクト)とコーディング屋さん(プログラマー)が分かれていた 17 データ分析などから ソフトウェア設計 設計をもとに コーディング
18. © DMM なにが問題か..? 1. 設計時のモデルとコーディング時の実装に乖離が生まれる 2. ビジネス側とプログラマー側の言葉に乖離が生まれる 18
19. © DMM 1.モデルの乖離 19 解決したい課題、モデルを設計できた！
20. © DMM 1.モデルの乖離 20 これでお願いします〜
21. © DMM 1.モデルの乖離 21 実装してからわかったけど、認証トークン の扱いどうしよう...? いまさら設計変えられないし、コードだけ変 えるしかないか...
22. © DMM 1.モデルの乖離 22 よし、設計とは違うけど動いた！
23. © DMM 1.モデルの乖離 23 設計とソースコードで乖 離がおこる
24. © DMM 1.モデルの乖離 24 設計とソースコードで乖 離がおこる 誰もメンテできなく...
25. © DMM 2.言葉の乖離 • ビジネス、業務領域に詳しい人、プログラマーで同じ言葉を使っていない • => 随時翻訳が必要 • => 同じ言葉を指しておらず、違う方を向いているので改善もされない 25 この案件では... このプロジェクトでは ... 正規表現でバリデーションする この条件の文字は弾きます
26. © DMM 再掲：2003年当時の課題 1. 設計時のモデルとコーディング時の実装に乖離が生まれる 2. ビジネス側とプログラマー側の言葉に乖離が生まれる 26
27. © DMM Eric Evansはどう解決しようとしたか 1. 設計時のモデルとコーディング時の実装に乖離が生まれる a. アジャイル的にモデルの改善（前提としてウォーターフローではない） b. ソースコードも含めてモデル（まさしくコードが情報源 (ソース)） 2. ビジネス側とプログラマー側の言葉に乖離が生まれる a. 同じ言葉を使おう（後述） 27
28. © DMM Eric Evansはどう解決しようとしたか 1. 設計時のモデルとコーディング時の実装に乖離が生まれる a. アジャイル的にモデルの改善（前提としてウォーターフローではない） b. ソースコードも含めてモデル（まさしくコードが情報源(ソース)） 2. ビジネス側とプログラマー側の言葉に乖離が生まれる a. 同じ言葉を使おう（後述） 28
29. © DMM 現代に行くにつれて • Ruby on Railsのような大きなフレームワークではアーキテクチャについ て考えることが少なかった • 2017, 2018年頃にはGoが流行りはじめ、Ruby on Railsの代わりとなる ような設計が求める開発者が多くいた • => 値オブジェクトやアーキテクチャなどの戦術的設計に目が行く • => 戦略的設計については省略されがち 29
30. © DMM いまとなっては(松本の所感) 1. 設計時のモデルとコーディング時の実装に乖離が生まれる a. Web系企業が主流になり、プログラマーがモデル設計までやることが当たり前に 2. ビジネス側とプログラマー側の言葉に乖離が生まれる a. こっちはいつでも問題意識があるので話題にあがりがち 30
31. © DMM ちょっと面白い書籍まわりの話 （より身近に感じるために）
32. © DMM 書籍まわりの話 • 2003年「Domain-Driven Design」出版 • 2011年「エリック・エヴァンスのドメイン駆動設計」出版 • 日本語訳が出るまでに８年かかった • 翻訳を丁寧に進めたかったかららしい 32
33. © DMM 2013年 ピアソンショック • 海外の技術書の翻訳版を出版していた「株式会社ピアソン桐原」 • ピアソングループから独立し「株式会社桐原書店」へ • 独立を機に技術書出版から離れることになり、多くの技術書が入手困難 に... • 設計まわりの技術書として、代表的な「エリック・エヴァンスのドメイン駆動 設計」が生き残った 33
34. © DMM 2013年 ピアソンショック 34 ピアソンショック - Scrapbox
35. © DMM CONFIDENTAL 第2部 事業の”中核” を分析しよう
36. © DMM みなさんはコードを書くのが好きですか？
37. © DMM 課題を見つけ、すっきりとした解法を模索し、 見通しの良いコードを書くことは本当に楽しいことです
38. © DMM 見通しの良いコードを書くためには ソフトウェアの対象について知る必要があります
39. © DMM しかし、開発リソースは有限です
40. © DMM 効果のある開発をしていかなければ 企業の利益が生み出せません
41. © DMM ソフトウェアの対象 • DMM動画、DMMブックス、DMMポイントクラブ、... • 会員基盤、検索基盤、データ基盤、... • これら一つ一つのサービスがソフトウェアの対象 41
42. © DMM ソフトウェアの対象 • DMM動画、DMMブックス、DMMポイントクラブ、... • 会員基盤、検索基盤、データ基盤、... • これら一つ一つのサービスがソフトウェアの対象 • それぞれ「効果の高い開発」、「見通しの良いコード」を実現するにはどう したらいか？ 42
43. © DMM どうやって効果の高い開発をするか？ • 仮になんらかのサービスに配属されたとして、どうやってそのサービスの 価値を知れば良いでしょうか？ • DMM ブックスのようなサービスだったら実際に使ってみる？ • どんなドキュメントを探す？ • そのサービスがウリにしているものとは？ 43
44. © DMM どうやって効果の高い開発を知るか？ • 想定回答 • 実際にサービスを使ってみる • Mission / Vision / Valueが書かれているページを探す • SNSでそのサービス名で検索してみる 44
45. © DMM 解決したい課題 • 効果の低い開発による機能性低下 • 効果の高い開発をするために、業務活動を理解したい • 見通しの悪いコードによる変更容易性の低下 • 見通しの良いコードを書くために、業務活動を理解したい 45
46. © DMM 中核、一般、補完 • ドメイン駆動設計では事業活動を３つのカテゴリーに分類 • 中核 • 一般 • 補完 46
47. © DMM 中核 • 競合他社との違いを生み出す業務活動 のこと • 例. Googleの検索アルゴリズム、Uberの相乗り最適化アルゴリズム、PayPayの 加盟店舗数、宝飾品メーカーの宝石デザイン、Amazon Primeに加入すると多く のAmazon系列のサービスが使えること • 技術的なものに限らない 47
48. © DMM 中核 • 中核は複雑でないと他社に真似されてしまう • 例. OpenAI社のChatGPT • すぐに他のAIサービスと肩を並べられてしまった（十分複雑だとは思うんだけど） • 複雑さや参入障壁が高いことは必須 • その点アダルト界隈は参入障壁が高い、と言えるかも 48
49. © DMM 一般 • 競争優位を生み出さないが、複雑な事業活動 のこと • 例. 認証、認可、宝飾品メーカーのECサイトの構築、メール送信サーバーの構 築、APIサーバーが動く環境の用意 • SaaSやクラウドサービスで置き換えられる • （DMMだとプラットフォーム開発本部の認証認可基盤を利用するなど） 49
50. © DMM 補完 • 他社と異なる、かつ簡単な事業活動 のこと • 競争優位は生み出さない • 例. マーテクの社内向け広告入稿管理画面、DMMブックスの出版社(または取 次)とのやり取り、goggle.com、drnrn.comなどタイポスクワッティングサイトの撤 去 • SaaSやクラウドサービスで置き換えられないが、事業活動に必要なもの 50
51. © DMM 競争優位 • 中核 • 中核の業務領域だけが競争優位を生み出す • 一般 • その定義から競争優位を生み出さない • 補完 • 他社も同じことが簡単にできるため、競争優位を生み出さない 51
52. © DMM 複雑さ • 中核 • 複雑。競争相手が容易にまねできないようにする必要がある • 一般 • 複雑。他社パッケージを使うのにはそれなりの理由がある • PFの認証認可基盤、AWS、Datadog、… • 補完 • 簡単。大抵がCRUD操作や妥当性検証、データ構造の変換だけ 52
53. © DMM 他社との差別化と複雑さ 53 競合他社との差別化 （競争優位ではない） 業務ロジックの 複雑さ 中核 補完 一般 一般または補完 小 大 大 小
54. © DMM 中核と補完の判断 • 中核と補完に関しては判断に迷うことが多い • そういったときは複雑さを考えてみる 54 Q.対象はビジネスとして成立しますか？ Q.お金を払ってもらえますか？ 中核 補完 Yes No
55. © DMM 一般と補完の判断 • 一般と補完に関しても複雑さで考えてみる 55 Q.自社よりも外部サービスを利用した方が安く簡単ですか？ （逆に、外部サービスを自社で作った方が安く簡単ですか？も考え てみる） 補完 Yes No 一般
56. © DMM 業務の分類 • 業務を細分化し、中核、一般、補完に分類していく 56 メルマガ配信 広告配信 人事 チーム管理 問い合わせ 対応 … 広告配信の細分化 配信入稿 システム （補完） 配信システム （中核） 配信ログ収集 システム （一般？） データ分析 （中核） … 配信基盤
57. © DMM 疑問1.どこまで分類すればいいのか（深さ） 57 さらに分類？ さらに分類？ さらに... 広告配信の細分化 配信入稿 システム （補完） 配信システム （中核） 配信ログ収集 システム （一般？） データ分析 （中核） …
58. © DMM 疑問2.なにを分類すればいいのか（対象） 58 さらに分類？ さらに分類？ さらに分類？ 広告配信の細分化 配信入稿 システム （補完） 配信システム （中核） 配信ログ収集 システム （一般？） データ分析 （中核） …
59. © DMM 分類の方針 59 • 中核のみユースケースが見えるまで分類 • 一般、補完は設計判断に影響が出なくなるまで分類
60. © DMM 中核のみユースケースが見えるまで分類 60 配信システム （中核） 配信 サーバー 通常広告表示 ポップアップ表示 「二度と表示しない」 ボタン押す ユーザー 配信システムのユースケース図 会員データを使ったレ コメンド広告表示
61. © DMM 一般、補完は設計判断に影響が出なくなるまで分類 61 配信ログ収集 システム （一般？） ログ分類 （一般） ログを保存 （一般） ログ検索 （一般） ログID発行 （一般） 配信サーバー へログ仕込む （補完） ログ削除 （一般） 深掘りしても一般 or 補完のみになったら問題なし ※ログ収集システムのイメージ: Datadog、NewRelic
62. © DMM 分類したあと
63. © DMM 中核、一般、補完の基本方針 • 一般、補完を無視して良いわけではなく、どれも必要 • （どれか一つ欠けても事業が成り立たなくなる） • 中核 • 自社開発がベスト • 外部に委託すると企業秘密漏洩の危険、かつ事業の存続に関わる • 一般 • 外部製品やOSSを使うのがコスパ良さそう • 例. Web上の動画プレイヤー、動画の圧縮アルゴリズム • 補完 • 外部製品でそのまま補えないので自社で作るしかない • とはいえ単純なので、なるべく早く作れるフレームワークなどを利用 63
64. © DMM コラム: 中核、一般、補完による選択 64 中核ですか？ お金、分析、監査の いずれかですか？ データ構造は 複雑ですか？ ドメインモデル イベント履歴式 ドメインモデル アクティブレコード トランザクション スクリプト はい いいえ いいえ いいえ はい はい
65. © DMM コラム: 設計判断 65 https://x.com/t_wada/status/1904856379036492190
66. © DMM 第2部 まとめ
67. © DMM 第2部：まとめ • 解決したかった課題 • 効果の低い開発による機能性低下 • 見通しの悪いコードによる変更容易性の低下 • 中核を見つけ、集中的に開発リソースを投入する • さらに、中核とそれ以外を分離し中核部分を開発しやすくする 67
68. © DMM CONFIDENTAL 第3部 “同じ言葉” を使おう
69. © DMM ビジネス(またはUI)上の用語とコードでの用語が 違った経験、ありませんか？
70. © DMM ビジネス(またはUI)上の用語とコードでの用語が 違った経験、ありませんか？ うっ... あるある あるある！ ぐっ ないなぁ ないと言いたい人生だった.. ばななぁ ありすぎてアリになった
71. © DMM 言葉が違う例 • ビジネス • 広告などでDMMプレミアムを宣伝している • 加入したユーザーはプレミアムユーザーという • コード • サブスクライブユーザーという名前 • 月額料金を情報として持っている 71
72. © DMM こんなことが起こったとする • プレミアムユーザーの月額料金を月550円から月990円に • コード • 月額料金の値を変更 72 簡単に変更できるね
73. © DMM こんなことが起こったとする２ • プレミアムユーザーの区分けが • スタンダードプレミアムユーザー：月550円 • リッチプレミアムユーザー：月990円 • コード • サブスクライブユーザーに種別を持たせることに • type = “standard” | “rich” 73 これでいくつ区分けされても 大丈夫だ
74. © DMM こんなことが起こったとする３ • 学生プレミアムユーザーとして、学生無料プランが登場 • クレカなど登録なしで学生情報だけで大丈夫 • コード • サブスクライブユーザーに学生プランを追加 74 サブスクライブしてないけど サブスクライブユーザー ...
75. © DMM こんなことが起こったとする４ • A社と連携し、A社課金ユーザーなら無料でプレミアムユーザーに • クレカなど登録なしで大丈夫 • コード • サブスクライブユーザーに他企業連携プランを追加 75 いよいよ わからなくなってきた ..
76. © DMM 今までの経緯を知らない社員がチームに配属 76 学生 プレミアムユーザー スタンダード プレミアムユーザー リッチ プレミアムユーザー サブスクライブ ユーザー クレカ 学生情報 乖離 わかりづらいよ〜 A社課金 プレミアムユーザー 連携企業 コード 仕様
77. © DMM さらに困ること • 意思疎通が取りづらい • ビジネス側はそもそも「サブスクライブユーザー」なんて知らない • 今後、意図が伝わらずに必要な機能が実装されない可能性 • コード上で用語の改善が行われづらい • 「コードとビジネス上の用語は違うもの」という認識が根付いてしまったら、改善は されない • 「もう慣れてしまったし...」「仕様書通りに実装しただけだし...」 77
78. © DMM 解決したい課題 • 機能性低下 • ビジネス側が意図していたものと違うものができあがる • 「これを作ってほしいわけではなくて...」 • 変更容易性低下 • 同じ言葉を扱わなかったがために、機能の改修が遅れる • 「プレミアムユーザーの月額料金を変えるには、サブスクライブユーザーの...」と 翻訳していく必要 78
79. © DMM ではどうするか • 全員が “同じ言葉” を使う 79 同じ言葉
80. © DMM 同じ言葉は業務エキスパートを参考に • 業務活動に特別詳しい人を「業務エキスパート」と呼ぶ • 例. • DMMブックス -> 「作者、出版社、取次」の関係を知っている人 • DMMバヌーシー -> 「馬主、馬飼い、競馬場」の関係を知っている人 • 動画 -> 「動画圧縮(FFmpeg, AV1)、ライセンス」を知っている人 • エンジニアとは限らない • 利用者、プロジェクト責任者など様々 80
81. © DMM 同じ言葉の定着 • 日常的にいたるところで使っていく • 「“本棚” 機能の実装お願いします〜」 • 「”トップページポップアップ” 機能の実装できました？」 • 用語集としてまとめておく • チーム内で更新していくコンフルなど • （更新忘れが怖いのでスプリントごとなどで振り返るタイミングを） 81
82. © DMM （余談）2003年 • 今となっては当たり前だよね、と思うかもしれませんが • 「Domain-Driven Design」が出版された 2003 年頃は当たり前ではな かった • 業務知識 => 分析モデル => 要件定義書 => 設計書 => コード • 業務知識や分析モデルとコードで全く別の言葉を使っていた 82
83. © DMM 第3部 まとめ
84. © DMM 第3部：まとめ • 解決したかった課題 • 意図していない開発による機能性低下 • 言葉の翻訳による変更容易性の低下 • 同じ言葉をすべての関係者が利用し、意図の減衰を防ぐ 84
85. © DMM CONFIDENTAL 第4部 “区切られた文脈 ” で分解しよう
86. © DMM 同じ言葉で困ること • 先ほど、 “同じ言葉” を紹介しました • しかし、困ることがあります • それは一体..? 86
87. © DMM 同じ言葉で困ること • 同音異義語がつらい 87
88. © DMM ユーザー =出品者 同音異義語がつらい • 通販系のサービスだとして 88 ユーザー用画面の実装お願いします〜 あ、はい〜 ユーザー =搬送者
89. © DMM • 機能性低下 • 文脈が異なることを理解せずに、本来求めていたものとは違うものを作ってしま う • 変更容易性低下 • 複数の意味を持つ巨大な一枚岩モデルが作られてしまうと変更しづらい 解決したい課題 89
90. © DMM “区切られた文脈” を設計する • “同じ言葉” は同じ意味で使うことが必要 • しかし、業務エキスパートの捉え方をそのまま映し出すのも必要 • 通販での出品と搬送は別々の業務エキスパートがいる • 出品の業務エキスパート • 出品元の小売店、グッズ制作店、プラモ制作店などに詳しい • グッズの制作費とか、受注生産の流れとか • 搬送の業務エキスパート • 搬送業者、クロネコヤマト、佐川急便などに詳しい • 郵便番号とか、離島への届け方とか 90
91. © DMM “区切られた文脈” を設計する • 出品の業務エキスパート • ユーザー：出品者 • 搬送の業務エキスパート • ユーザー：搬送業者 91 業務エキスパートの捉え方をそのまま使いたいが、 意味がかぶってしまう...
92. © DMM “区切られた文脈” を設計する • そこで、 “区切られた文脈” を設計する 92 出品の文脈 搬送の文脈 ユーザー ユーザー 出品者 搬送業者
93. © DMM “同じ言葉” の定義（改良版） • “同じ言葉” は組織全体で統一した言葉を使うわけではない • “区切られた文脈” の中で、 “同じ言葉” を使う 93 出品の文脈 搬送の文脈 ユーザー ユーザー
94. © DMM 区切られた文脈の大きさはどうするか • 取り組んでいる課題しだい • 対象範囲を広げた方が良い場合 • 開発チームが iOS、Android で分かれていたが Flutter にするため、区切られた 文脈もともなって広げた • 対象範囲を狭めた方が良い場合 • マイクロサービス的に運用するため、認証認可基盤を認証基盤、認可基盤に分 け、区切られた文脈もともなって分けた 94
95. © DMM 区切られた文脈とチーム • 一つの区切られた文脈を複数のチームが担当するのはNG 95 搬送の文脈 ユーザー 搬送管理画面 チーム 搬送システムチーム
96. © DMM 区切られた文脈とチーム • 複数の区切られた文脈を一つのチームが担当するのはOK 96 出品の文脈 通販チーム 搬送の文脈
97. © DMM 区切られた文脈とチーム • チームが別々だと、 “同じ言葉” の変更が大変 • 実装面を考えると、機能のリリースタイミングとかも揃える必要 • 別のチームが変更した要素を追いかけるのも大変 97
98. © DMM 区切られた文脈はどう実現するの？ • 実現パターンが多すぎるので、その時にあった方法で • （モデルや同じ言葉が違うことを認識するのが重要） • 同じチームの場合 • 別々のリポジトリに分ける（配送システム、出品システム） • 同じリポジトリだが、ディレクトリで分ける（同じ構造体を共有するため） • など • 別チームの場合 • マイクロサービス的にサービスを分ける（認証基盤、認可基盤、データ基盤） • 変換サーバーを間に設ける（BFFのような） • など 98
99. © DMM 第4部 まとめ
100. © DMM 第4部：まとめ • 解決したかった課題 • 意図していない開発による機能性低下 • 複数の意味を持つモデルによる変更容易性の低下 • 区切られた文脈を設計し、各文脈に特化したモデルを作る 100
101. © DMM CONFIDENTAL おわりに
102. © DMM おわりに • 「ドメイン駆動設計？ちょっとわかる」になってますか • 講義前よりかは「ちょっとわかる」になってるのではないでしょうか 102
103. © DMM CONFIDENTAL 参考
104. © DMM 参考 • ドメイン駆動設計をはじめよう - O’reilly Japan • texta.fm: 1. Software Development in 2003 - Spotify • ドメイン駆動設計の正体 - Zenn • ピアソンショック - Scrapbox • Domain-Driven Design - Amazon • Patterns of Enterprise Application Architecture - Amazon • アジャイルソフトウェア開発宣言 104
105. © DMM ご清聴ありがとうございました