設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち

by panda_program

Slide 1

Slide 1 text

@PHP Conference Japan 2025（2025/6/28）プログラミングをするパンダ（@Panda_Program）設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち 1

Slide 2

Slide 2 text

ペチコン25周年おめでとうございます！ PHP Conference Japan 25周年おめでとうございます！ 22

Slide 3

Slide 3 text

3 © 2012-2025 BASE, Inc. 自己紹介 ● BASE株式会社 ● 所属：BASE / Product Dev / feature dev1 ● 現在の仕事：Advanced Enginner（ジュニアテックリード相当） ○ フロントエンドもバックエンドも書くフルスタックです ○ スクラム開発やチーム開発のプロセス改善が好きです ○ 今はフロント中心にサイトリニューアルPJを担当しています（8ヶ月目） ● 活動実績 ○ 執筆 ○ CodeZine様で「バックエンドエンジニアのためのフロントエンド入門」を連載 ○ 2024/12に「アジャイル開発」で一人アドベントカレンダーを完走しました ○ 登壇実績 ○ Developers Summit 2025、PHPerKaigi 2025、TSKaigi 2025, PHP Conference JP 2022 など ○ twitter: @Panda_Program プログラミングをするパンダ（@Panda_Program）

Slide 4

Slide 4 text

Slide 5

Slide 5 text

5 © 2012-2025 BASE, Inc. 宣伝 YouTubeでエンジニア向けのラジオを配信してます（@dialog-radio） https://www.youtube.com/@dialog-radio/videos ● ブログや登壇とはまた違った内容です ○ プロダクトエンジニアって何だろう？ ○ プロダクトオーナーとエンジニアの違いとは？ ○ 勉強会のスキルアップ以外の意義とは？ ● 毎週月曜日、朝7時配信 ○ ぜひご視聴 & チャンネル登録お願いします！

Slide 6

Slide 6 text

Slide 7

Slide 7 text

本発表の背景

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 2012-2025 BASE, Inc. 本発表の背景 ● リーダブルコードの次に読んでほしい書籍 ● クラス設計、実装に使える ○ 自然にSOLID原則が身につく ■ 自然にクリーンアーキテクチャも身につく ○ 自然に”Always-Valid Domain Model”が書ける ○ 自然にCQS、CQRSが身につく ● チームで読んだら、同じ視点・同じレベルで相互にコードレビューができる本発表はスタイルガイド本を参考にしている 10 10

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

1. クリーンなコードを書く・読む・説明する

Slide 15

Slide 15 text

© 2012-2025 BASE, Inc. クリーンなコードを書く・読む・説明するクリーンなコードとは何か ● そもそもクリーンなコードとは何か ○ 認知負荷が低いコード ○ （ただし、クリーンなコードは認知負荷が低いが、認知負荷が低いコードは必ずしもクリーンなコードとは限らない） ● 認知負荷が低いコードとは何か ○ 自分が過去に見たことがある書き方をしているコードである（既知） ○ コードと仕様の対応関係がわかる（意図） ○ 処理内容がわかりやすい 15 15

Slide 16

Slide 16 text

© 2012-2025 BASE, Inc. クリーンなコードとは何か ● 何が処理内容がわかりやすいコードなのか ○ 定量・定性の両面がある ○ 定量: 「凝集度が高く、結合度が低い」「循環的複雑度（Cyclomatic Complexity）が低い」 ○ 定性: 「構造を表現している」「整頓されたコード（Tidy）」「命名がわかりやすい」 ● つまり ○ 「予想と一致する」「直感的にわかる」が認知負荷の低いコード ○ パターン化されているコード（パターンランゲージ） ● チーム開発では自分一人が書ければいいというものではない 16 16 クリーンなコードを書く・読む・説明する

Slide 17

Slide 17 text

© 2012-2025 BASE, Inc. 具体的なエピソード ● 転職者の若手と同じチームになった ○ Laravel でコントローラーにロジックを全部書いていたとのこと ● コードレビューで「これは VO に切り出すと管理が楽ですよ」とコメントした ● 「VO ってValue Objectですか？なぜ VO にしないといけないんですか？」 ○ 説明したり、ネットの記事を渡してもいまいち納得していない様子 ● 自分一人が「クリーンなコードを書ければいい」のではない ● 「チーム全員」が「同じ基準」でコードを書くことが重要 ○ 一般的な原則を基準とする ○ 他の人が書くコードと「自分ならこう書く」が一致する ○ = パターン化されている ● このために「スタイルガイド本」が最適 17 17 クリーンなコードを書く・読む・説明する

Slide 18

Slide 18 text

© 2012-2025 BASE, Inc. 改めてクリーンなコードとは ● コードが一般的な原則に従っていること ○ CQS, SOLID 原則, DRY 原則 etc. ○ 「プリンシプルオブプログラミング」がおすすめ ● パターン化されていること ○ 人間のパターンマッチング ○ 「この場合はこう書く」が浸透している ○ 説明不要の共通言語を使える → コミュニケーションコストの低減 ● 自分のみならず、チーム内、チーム外の人も理解しやすいこと → AI も理解しやすい ● 第2, 3章で、オブジェクト設計の一般原則に則りパターン化されたコードを解説 18 18 クリーンなコードを書く・読む・説明する

Slide 19

Slide 19 text

2. オブジェクト指向アプリケーションの構成要素

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© 2012-2025 BASE, Inc. オブジェクト指向アプリケーションの構成要素構成要素 - レイヤー ● インフラ層 ○ コントローラー ○ レポジトリとクエリサービスの実装 ● アプリケーション層 ○ コマンドオブジェクト, リードモデル ○ クエリサービスのインターフェース ○ イベントリスナー ● ドメイン層 ○ エンティティ ○ バリューオブジェクト ○ レポジトリのインターフェース出典:『オブジェクト指向設計スタイルガイド』レイヤーとそれに属するオブジェクト 21 21

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

3.オブジェクトとメソッドのコード例

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© 2012-2025 BASE, Inc. オブジェクトとメソッドのコード例 ● 特徴 ○ コントローラーはサービスのエントリーポイントである ○ アプリケーションサービスかクエリサービスを呼び出している ○ Web の Controller の場合、必ず返り値（レスポンス）が必要 ● レビューの視点 ○ ドメインロジックが書かれていないか？（ドメインロジックはEntityかValue Objectに書く）サービス - コントローラー 29 29

Slide 30

Slide 30 text

© 2012-2025 BASE, Inc. オブジェクトとメソッドのコード例 ● 特徴 ○ 単一のタスクを実行する ○ ドメイン層にのみ依存する ○ インフラ層のコードを含まない ● レビューの視点 ○ 複数のタスクを実行していないか？ ○ 抽象（Interface）ではなく具象（クラス）に依存していないか？ ○ ドメインモデルの呼び出しかトランザクションスクリプトか？サービス - アプリケーションサービス 30 30

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© 2012-2025 BASE, Inc. オブジェクトとメソッドのコード例 ● 特徴 ○ 永続化先からデータを取得する（PDOは使わなくても良い） ○ 特定のユースケースに応じて柔軟にデータを返す ○ 専用の DTO を返す ● レビューの視点 ○ DTO を使い回してはいないか？ ○ レポジトリのクエリメソッドで代用できないか？（単純な値ならクエリサービスを作成する必要なし）サービス - クエリサービス 32 32

Slide 33

Slide 33 text

© 2012-2025 BASE, Inc. オブジェクトとメソッドのコード例 ● 特徴 ○ Entityが持つデータを永続化先に保存する ○ 永続化先からデータを取得し、 Entityを復元する ● レビューの視点 ○ ドメインロジックを書いてはいないか？（ドメインロジックはEntityかValue Objectに書く） ○ 返り値は DTO ではなく Entity であるか？サービス - レポジトリ 33 33

Slide 34

Slide 34 text

© 2012-2025 BASE, Inc. オブジェクトとメソッドのコード例 ● 英語から意味を考える ○ 他と区別できる「実在物」 ○ ex. 会場、座席、テーブル ● Entity は ○ 他と区別するための ID を持つ ○ Entity and Identity ○ 「作成→変更→削除」のライフサイクルがある ○ 永続化され、復元される ○ プロパティにValue Objectを持つ ○ データの変更ができるサービス以外のオブジェクト - Entity 34 34

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© 2012-2025 BASE, Inc. オブジェクトとメソッドのコード例 ● 英語から意味を考える ○ 「値」「オブジェクト」 ● value（値）との違い ○ value はコンピュータが扱える範囲で取りうる全ての値（無制限） ○ value はスカラ型、VOは Object ● Value Object は ○ スカラ型の値をラップしているオブジェクトである ○ 値の範囲をバリデーションで制限 ○ イミュータブルである ○ サービス以外のオブジェクト - Value Object 36 36

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© 2012-2025 BASE, Inc. オブジェクトとメソッドのコード例 ● 特徴 ○ DTO は振る舞いを持たないデータの塊である ○ データの箱 ○ システムの境界で現れる ● レビューの視点 ○ プロパティはプリミティブ型か？（EntityやVOを持たせてはいけない） ○ readonlyにしているか？（ただし、好みがあるので絶対ではない）サービス以外のオブジェクト - DTO 38 38

Slide 39

Slide 39 text

Slide 40

Slide 40 text

© 2012-2025 BASE, Inc. オブジェクトとメソッドのコード例 ● 特徴 ○ メソッドの具体的な実装ではなく、抽象的なシグニチャを定義（シグニチャ = メソッド名・引数・返り値の型） ■ 「IFは契約」と呼ばれる理由 ○ ポリモーフィズムを実現するために使われる（次ページ） ○ 制御できないものを抽象化する ● レビューの視点 ○ メソッドはクエリメソッドかコマンドメソッドかわかる命名か？その他 - Interface 40 40

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© 2012-2025 BASE, Inc. オブジェクトとメソッドのコード例サービスとEntity, Value Objectの違い ● 他のオブジェクトに仕事をさせる / 呼び出されるまで待機中 ○ サービスは舞台、それ以外のオブジェクトは役者、永続化先は役者の家 ● 依存する側 / 依存される側 ● テストのためにモックやスタブを使う / そのままテストができる ● （大まかに）例外は RuntimeException を投げる / LogicException を投げる（ドメイン層、サービス層などのレイヤーについては TSKaigi 2025のクリーンアーキテクチャの発表をご覧ください）（「クリーンなアプリケーション」を1つのモジュールとした大規模なアプリケーションについては、PHPer Kaigi 2025のモジュラーモノリスの発表をご覧ください） 42 42

Slide 43

Slide 43 text

© 2012-2025 BASE, Inc. オブジェクトとメソッドのコード例 3つにレイヤーを分けて（Domain Layer, Application Layer, Infrastructure Layer） 4種類のオブジェクトと（Service, Entity, Value Object, DTO） 3種類のメソッドを使って（Command Method, Query Method, Modiﬁer Method）クリーンなコードを書く 43 43

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

ペチコン25周年盛り上げていきましょう！ PHP Conference Japan 25周年盛り上げていきましょう！ 46 46

Slide 47

Slide 47 text

（appendix） MVC フレームワーク vs. 「クリーン」なアプリケーション

Slide 48

Slide 48 text

© 2012-2025 BASE, Inc. MVC FW vs.「クリーン」なアプリケーション SOLID原則に基づいた Clean Way* vs. MVCフレームワーク Way（Rails Way） ● 疎結合 vs. 密結合 ● 高凝集 vs. 低凝集 ● 単一責任 vs. 複数の責務 ● 単体テスト中心 vs. 結合テスト中心 ● アプリケーションの内外を Interface で区別 vs. コントローラーからDBも呼ぶ ● 処理をサービスに移譲 vs. Fat Controller, Fat Model ● etc. （「右はマイナスだ」とされるのは2025年時点の感覚。2000年代後半には左のアンチテーゼとしてWeb開発むけのMVCフレームワークが登場した。もちろん現代でもMVCフレームワークの良さはある）（* サービス層とドメイン層を分けるレイヤードアーキテクチャとClean Architectureの設計に着目し、オブジェクト指向の一般的な原則に則った設計をRails Way と対比する形でここでは便宜的にClean Wayと呼ぶ（他では通じないのでご注意）） 48 48

Slide 49

Slide 49 text

Slide 50

Slide 50 text

© 2012-2025 BASE, Inc. MVC FW vs.「クリーン」なアプリケーション Q. なぜ MVC フレームワークから距離を置く手法が流行っているのか？ A.スタートアップが成長した結果、設計が見直されたから（SaaS隆盛で加速） — 2000年代中盤まで: エンタープライズ向けの重厚なアプリケーション設計が主流(？) 2000年代中盤: Rails 登場、軽量な Rails Way で爆速開発（スタートアップの世界） 2010年代: スタートアップで事業の成長から Fat Model + Fat Controller へ 2010年代後半: → DDD再脚光、Clean Architecture 広まる私見 ● フレームワークからアプリケーションを分離する手段 ● スタートアップ特有の事情 ○ 戦略的DDDが軽視された理由 ■ 実装だけに注目・事業成長優先・モデリング軽視先に整頓する？ 50 50

Slide 51

Slide 51 text

© 2012-2025 BASE, Inc. MVC FW vs.「クリーン」なアプリケーション Clean Way と Rails Way の違いは「アプリケーション」の捉え方の違いと思われる ● Rails Way では Controller や Database までアプリケーションとして捉えているのでは？ ○ ex. リクエストのバリデーションをモデルでやる ● クリーンアーキテクチャは、ドメイン層とUseCase層しかアプリケーションと捉えていない ● クリーンアーキテクチャに対する「DBは外側ではないでしょ？」に対する回答 51 51

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

© 2012-2025 BASE, Inc. 参考資料 ● スライドに掲載した各書籍 ● 「1. Software Development in 2003（技術顧問の和田卓人さんと、DDD、データソースのアーキテクチャに関するパターンなどについて話しました）」 texta.fm ○ https://open.spotify.com/episode/1Ka5Fnoe89SyRLPea5twPA ● Special Thanks to ○ Claude Code（サンプルコード生成） ○ k1LoW/deck（スライド作成） ■ https://github.com/k1LoW/deck 54 54

Slide 55

Slide 55 text

ペチコン25周年盛り上げていきましょう！ PHP Conference Japan 25周年盛り上げていきましょう！ 55 55