DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁

"Object-Oriented Conference 2024" の登壇資料です。
https://ooc.connpass.com/event/305241/

1. DDDはなぜ難しいのか 良いコードの定義と設計能力の壁 @pospome
2. 登壇者 名前：pospome（ぽすぽめ） 所属：DMMプラットフォーム Twitter:@pospome
3. 目次 • DDDとの出会いと挫折 • DDDを理解する • 良いコードの定義 • 設計能力の壁
4. 目次 • DDDとの出会いと挫折 • DDDを理解する • 良いコードの定義 • 設計能力の壁
5. DDDとの出会い • 2013年くらいにDDD本を見つけて読んでみた。 ◦ ちょうど設計に興味を持っていた。 ◦ 頑張って読んだが、よく分からなかった・・・。 ◦ レイヤアーキテクチャ = DDD だと思っていた・・・。
6. 学習の日々 • 当時は今ほど情報が充実していなかった。 ◦ 勉強会に行って有識者に質問した。 ◦ DDD本をもう一度読んでみた。 • 最初よりは理解度が上がった気がした。 ◦ 戦略面、戦術面のプラクティスを覚えた。
7. 挫折 • いまいちピンとこない・・・。 ◦ 上手く設計できている気がしない・・・。 ◦ 自分が取り組んでいるのはDDDなのだろうか・・・?
8. 目次 • DDDとの出会いと挫折 • DDDを理解する • 良いコードの定義 • 設計能力の壁
9. そもそもDDDってなに? • 当時のpospomeはDDDを構成するプラクティスばかり気にしていた。 ◦ 例：エンティティ、レイヤアーキテクチャ、ドメインモデリング • DDDそのものを知ろうとしなかった。 ◦ DDDという設計手法は何のために生まれたのか? ◦ DDDじゃない設計手法は何なのか? • 挫折の正体に気付けない。
10. そもそもドメインってなに? • 英語の “Domain” には “領地、領域” という意味がある。 ◦ URLにおけるドメインも “領域” を示している。
11. DDD本にも記載がある • p2 “ユーザーがソフトウェアを適用する、この対象領域がソフトウェアのドメイ ンである。” ◦ 当時のpospomeは読み飛ばしていた・・・。 • ドメイン = ソフトウェアを適用する領域 ◦ 例：メルカリ = フリーマーケット、マネーフォワード = 家計簿
12. “駆動” ってなに? • DDD = ソフトウェアを適用する領域駆動設計 ◦ 駆動ってなに・・・? ◦ DDDに出会う前のpospomeは何駆動が開発だったのか? ◦ 何をすればDDDになるのか?
13. DB駆動設計 • 当時のpospomeがやっていたのは強いていうと “DB駆動設計” だった。 ◦ DBのテーブルと1対1でドメインオブジェクトを用意する。 ▪ ORMを利用するので、これが自然だった。 ▪ 今も主流だと思う。 • 今思い返すと設計という設計は不要だった記憶がある。 ◦ テーブル設計が実質的な設計作業だった。
14. DB駆動設計の問題点 • DBのデータ構造はプログラミングに適した構造になっていない。 ◦ あくまでデータ管理に適した構造になっている。 ◦ プログラミングにはDBにない要素がある。 ▪ メソッド、アクセス修飾子、モジュール • 無理やりプログラミングで利用すると中長期的に辛くなってくる。
15. DB駆動設計の例 • “商品の価格を計算する” というユースケースを考える。 • キャンペーン中であれば、割引が適用される。
16. DB駆動設計の例 • DB駆動設計では、商品テーブル、キャンペーンテーブルに対応した 商品クラスとキャンペーンクラスが存在する。
17. DB駆動設計の例 • 商品クラスとキャンペーンクラスの データ構造は以下である。
18. DB駆動設計の例 • 商品の価格を計算する ロジックはこちら。 • アプリケーションレイヤに ベタ書きしている状態。 • 割引を考慮する。
19. DB駆動設計の例 • 単体のクラスが持つ値にのみ 依存するロジックは そのクラスのメソッドとして 実装することができる。 • トランザクションスクリプトを 回避できる。
20. DB駆動設計の例 • 割引期間かどうかを 判断するメソッドの実装。 • アプリケーションレイヤに ベタ書きされていた実装を メソッドに移植しただけ。
21. DB駆動設計の例 • 商品価格を計算するロジックは 依然として アプリケーションレイヤに ベタ書きされている。 • ItemとCampaignに 依存する形になっている。
22. DB駆動設計の例 • Itemに計算ロジックを 寄せている。 • アプリケーションレイヤから ロジックを排除することが できた。
23. DB駆動設計の例 • Itemのメソッドはこちら。 • DB駆動設計でも上手い具合に ロジックをドメインレイヤに 実装できている。 • 特に困ることなさそうだけど・・・。
24. DB駆動設計の罠 • サンプルコードだから上手くいっているだけ。 • 実際に扱う実装はもっと複雑なはず。 ◦ テーブルの数が多い。 ◦ テーブルが持つ属性の数が多い。 ◦ 多くのクラスにまたがるロジックがある。 • 巨大なクラス同士が複雑に依存し合ってしまい、 中長期的に Fat Model になってしまう。
25. Fat Model • Item, CampaignもFat Modelに なる可能性がある。 • Item, Campaignそれぞれが 多くの値を持つので、 それらに関するロジックが Item, Campaignに寄ってしまう。 • 神クラスが誕生する。
26. ドメインモデル貧血症 • Fat Modelを回避するために アプリケーションレイヤに 切り出してしまうと、 ドメインモデル貧血症になる。 • 一時期流行ったサービスレイヤ とかがこれにあたる。
27. どうすべきか? • プログラミングに適したデータ構造（クラス設計）を採用する。 • DB構造をそのままプログラミングに利用するのは厳しい。 ◦ Fat Model ◦ ドメインモデル貧血症
28. Fat Modelを回避する例 • 商品価格を計算する際に 必要となる値のみを持ったクラスを 用意する。 • Discountという構造体を用意する。
29. Fat Modelを回避する例 • Priceという型を用意する。 • ItemとCampaignの結合から PriceとDiscountの結合に変更することで、 Fat Modelを回避することができる。 • Discount, Priceという小さいパーツによって コードの再利用性も向上する。
30. DB構造とクラス構造のミスマッチ • プログラミングとしての 正しさを考慮すると、 DB構造とクラス構造が 一致するとは限らない。
31. Fat Modelを回避する例 その2 • ItemにDiscountを直接もたせる選択肢も あるかもしれない。 ◦ 正しいかどうかは別問題。
32. Fat Modelを回避する例 その3 • Item, Discountを持つ 新たな構造体を 定義するのがいいかもしれない。
33. DDDはドメインレイヤの実装に自由度を与える • 設計の自由度を高くすることによって、 多くの手札から最適なものを切ることができる。 ◦ ドメインモデル貧血症やFat Modelを回避することができる。 • DB駆動設計では得られないメリットを得ることができる。
34. DB駆動設計の問題点 • DBにとって最適なデータ構造をプログラミングで利用すると、 ドメインで設計を駆動することが難しくなる。 ◦ サンプルコード微妙だったかもしれないですけど・・・。 • 大規模なシステムになればなるほど辛くなる。 ◦ 逆に小規模であればDB駆動設計でも耐えられる。 • プログラミングに適したクラス設計を心がける。
35. 補足：リポジトリパターンによるデータ差分の吸収 • DB構造とクラス構造の差分は以下のような形で吸収する必要があるので、 わりと面倒ではある。
36. “ドメイン駆動” の意味 • ソフトウェアの適用領域に対して適切な設計をする。 ◦ “ドメインで設計を駆動” できるように、 ドメインレイヤの設計に自由度を与える。 ◦ DBなどのデータ構造をプログラミングに流用しない。 ▪ たまたま一致することはある。
37. ドメイン駆動の重要性 • 競合他社に勝っていくには、 独自の機能や利便性を追求する必要があり、 それに伴う仮説検証もしたい。 ◦ システム仕様を担うドメインレイヤを素早く変更する必要がある。 ◦ DB構造の都合に合わせてプログラムを書いてられない。
38. ここまでのまとめ：ドメイン駆動設計に対する理解 • ドメイン = ソフトウェアを適用する領域 • ドメイン駆動 = ドメインに適した設計をする。 ◦ DBなどのデータ構造に依存しないようにする。 ◦ 競合他社に勝てるように。 • 当時のpospomeはDB駆動設計でDDDを実践しようとしていた。 ◦ ずっと辛かったのはこれが原因だった。 ◦ Fat Modelを避けてドメインモデル貧血症が発生していた。
39. 目次 • DDDとの出会いと挫折 • DDDを理解する • 良いコードの定義 • 設計能力の壁
40. ドメインに対して適切な設計をする • ドメインに対して適切な設計をしよう。 ◦ 設計の自由度を高くしたドメインレイヤを どのように設計するかが腕の見せ所。 ◦ 一番楽しく、一番悩む。
41. 設計方法が分からない問題 • DB駆動設計をしていた人ほど適切な設計が分からない。 ◦ テーブル設計しかしてこなかったのが原因。
42. ICONIXによるドメインモデリング • 増田亨さんが「ICONIXいいよ」って言ってた。 • ドメインモデル図を書いたり、 ユースケース図を書いたり・・・。 • ドメインを図にすることで、 理解を深めつつ、実装に落とし込む。 ＊当時増田さんにはめちゃくちゃお世話になりました。
43. 例：ドメインモデル図
44. 例：ユースケース図
45. 例：ロバストネス図
46. 例：シーケンス図
47. 図を書くだけでは上手く設計できない • 結論から言うと上手く設計できなかった。 ◦ なんとなく書いた図がそのまま良い設計になるわけがない。
48. 図を書くだけでは上手く設計できない • ICONIXも最終的には人による良し悪しの判断が必要になる。
49. ドメインと実装のフィードバックループ • DDDは設計手法であり、成果物はコードである。 ◦ 実装における良し悪しが最重要である。 ◦ 実装を最適化する過程で得た知見を 自身の理解に還元する。 • あくまで実装ファーストで物事を考える。 このフローが重要→
50. 図を書くだけでは上手く設計できない • DDDの各種プラクティスに対する知識があっても 設計できるかどうかは別問題である。 ◦ エンティティという概念を知っていても、 どんなエンティティを設計すればいいかが分からない。 ◦ DDDのプラクティスを理解していない人は理解しましょう。
51. 良いコードとは? • ドメインモデリングによって生まれた実装を最適化するには、 “良いコード” の定義や要件を明確にしなければいけない。
52. ソフトウェア品質モデル ISO/IEC 25010 というソフトウェア品質モデルがある。 今回の発表における “良いコード” の定義は “保守性” に該当する。
53. ソフトウェア品質モデル 保守性には5つの特性がある。 これらを満たせば良さそう。 • モジュール性 • 再利用性 • 解析性 • 修正性 • 試験性
54. モジュール性 • 変更による影響が最小になっている度合い。 ◦ 高凝集、疎結合なモジュールを目指す。 ◦ 安定度と依存方向の制御も考慮する。
55. 再利用性 • 他のシステムに資産を利用できる度合い。 ◦ “他のシステムに” という話だと、意識する機会は少ないと思う。
56. 解析性 • 故障原因の診断、修正箇所の識別の効率性の度合い。 ◦ スタックトレースやエラーログの出力が該当するが、 コード自体の可読性も対象になる。
57. 修正性 • 効率的にシステムを修正することができる度合い。 ◦ “競合他社に勝つため” に求められる。 ◦ モジュール性と解析性に左右される。
58. 試験性 • 試験を実行する際の効率性の度合い。 ◦ テストが可能な設計にする必要がある。 ◦ ユニットテストを書いたり、 インテグレーションテストを自動化することも重要。
59. ソフトウェア品質モデルを満たせばよさそう なんらかの形で以下を満たせば良さそう。 • モジュール性 • 再利用性 • 解析性 • 修正性 • 試験性
60. 目次 • DDDとの出会いと挫折 • DDDを理解する • 良いコードの定義 • 設計能力の壁
61. ソフトウェア品質モデルを満たせばよさそう どうすれば満たせるのか? • モジュール性 • 再利用性 • 解析性 • 修正性 • 試験性
62. 定義の抽象度が高い • モジュール性の定義 ◦ 変更による影響が最小になっている度合い。 ↑ これが実現できれば苦労しない・・・。
63. 設計の基礎力を固める 必要になる知識を挙げるとキリがない・・・。 • DRY原則 • ポリモーフィズム • SOLID原則 • 凝集度、結合度 • パッケージの安定度制御 • DI戦略 などなど・・・
64. 設計の基礎力を固める “ItemにDiscountを持たせる” vs “ItemのメソッドにDiscountを渡す”
65. 最適解はケースバイケース • システム仕様、テクノロジースタック、チームメンバーのスキルによって、最適解が 変わってくる。 ◦ 「どの程度xxxするか」を都度考えなければいけない。 ◦ “知っていること” と “できること” は別物。
66. 設計能力の壁 • ドメインレイヤをドメイン駆動で設計するには、 プログラミングの基礎力が必要になってしまう。 ◦ これがある意味 “壁” として立ちはだかる。 ◦ DDD本が与えてくれるのはプラクティスのみ。 ▪ 具体的なコードの良し悪しは自身で判断する必要がある。
67. 設計能力の壁 • 設計能力が低い人やチームがDDDを実践すると沼る可能性がある。 ◦ ドメインレイヤの設計が上手くできず、 時間を消費する割にコードの品質が低い状態になってしまう。 ◦ むしろDB駆動設計の方が開発自体は上手くいくケースが多い。 DB駆動設計はある意味優秀だったりする。
68. 設計能力の壁を打ち破るには? • 自分で頑張って勉強する。 ◦ 結構時間がかかりそう。 • 設計スキルの高い人に教えてもらう。 ◦ これが一番いい。 ◦ チーム内に強い人がいて、 現場のコードベースでレビューしてもらうのが理想。 ◦ 技術支援という形だと効果が微妙かもしれない。
69. pospomeはとにかく勉強した • 言語や手法に関わらず設計系の書籍を読み漁った。 ◦ ざっくりカウントすると30冊以上読んでいた。 ◦ SOLID原則などの有名なものはネットの情報で学んだ。
70. アウトプットが重要 • 現場のコードで試してみた。 ◦ 実践してみないと分からない。 • サンプルコードを書いてみた。 ◦ 例：ソシャゲのガチャでStrategyパターンを使ってみる。 ◦ TODOアプリみたいな簡単なものだと意味がない。
71. アウトプットが重要 • 社外イベントへの登壇、ブログ執筆、同人誌の執筆 ◦ 自身の知識を体系的に整理できる。 ◦ 取り組む過程で新しい気付きがある。 ◦ 成果物に対するフィードバックによって新しい気付きがある。 ◦ 自身のブランディングになる。 ▪ キャリアパスの形成に有利に働くことがある。
72. 継続すると設計の引き出しができてくる 例： • アプリケーションレイヤに if, for, 四則演算があると ドメインモデル貧血症の兆候があるので注意する。 • 結合度はスタンプ結合と制御結合だけ気にすれば良い。 • 関数やメソッドの戻り値が配列だった場合は、 配列加工のロジックが散っていないか確認する。 必要に応じてファーストクラスコレクションを提供する。
73. まとめ • DDDを実践するにはドメインに適した設計をする必要がある。 ◦ DBのデータ構造に依存したクラス設計は避ける。 • 良いコードの定義を明確にすること。 ◦ 今回の発表では品質モデルを取り上げた。 • DDDの難しさは設計の難しさ。 ◦ 頑張って勉強するしかない。
74. 補足：DMMプラットフォームにおける組織的なサポート pospomeが所属するDMMプラットフォームでは、 コード品質を向上させるための環境構築を進めている。 • コードランク • レビューシステム
75. 補足：コードランク • 静的解析によってコード品質をランク付けする。 「最低限これはやってほしい」に対する共通認識を持つ。
76. 補足：レビューシステム • 設計能力の高いエンジニアが各チームのコードをレビューする。 ◦ 擬似的に強いエンジニアと一緒に働ける環境を再現する。 ◦ 静的解析（コードランク）ではケアできない部分を人間がカバーする。