人には人それぞれのサービス層がある

PHPカンファレンス新潟2025 の発表資料になります
#phpcon_niigata #a

Transcript

1. 人には人それぞれの サービス層がある 2025/05/31 PHPカンファレンス新潟2025 by しまぶ@shimabox
2. NAME: "しまぶ" SNS: "@shimabox" TAMASHII: "沖縄" COMPANY: "カオナビ" SKILL: - "PHP" - "Go" NIIGATA: "生まれてはじめて" whoami.yml 2 自己紹介
3. 3 📖 共著で本を書きました 📖
4. 人には人それぞれの サービス層がある 4 ふざけたタイトル
5. 5 【おことわり】わたしが今回話そうとしているサービス層の定義 用語 主な役割 サービス層 • MVCにおけるControllerとModelの間にいる アプリケーション サービス （DDD） • ユースケースを実現する ◦ クリーンアーキテクチャでは UseCaseInteractor • 「〜したい」という目的を実行 • 例)「ユーザー登録をしたい」「請求書を発行したい」 • ドメインモデルと会話、協調する ドメインサービス （DDD） • エンティティや値オブジェクトに収まらないドメインロジック • 例) 送金サービス（2つの口座間の振替） • 作りすぎると貧血と呼ばれる ❌ ❌ 👈
6. とある日常 6 なぜ話そうと思ったのか うーん、ここの実装ど うしようかな。。 コントローラーは用意 して、あの処理はどう しようかな、、せや、 サービスにして作ろ うっと！
7. とある日常 7 なぜ話そうと思ったのか うーん、ここの実装ど うしようかな。。 コントローラーは用意 して、あの処理はどう しようかな、、せや、 サービスにして作ろ うっと！ この思考、 稀によくある！！
8. とある日常 8 なぜ話そうと思ったのか サービス層に処理を 切り出すってけっこう カジュアルに考えちゃ うけど、、、
9. とある日常 9 なぜ話そうと思ったのか 何のためにサービス層 があって、どんなサー ビスクラスが置かれる べきなんだろう... 何か正解ってあるんだ ろうか？？？
10. 10 わたしが今回話そうとしているサービス層 かんたんに言うと、MでもCでもないやつら サービスクラスのありがたみを発見したときの思い出 #phpcon_odawara https://speakerdeck.com/77web/sabisukurasunoarigatamiwofa-jian-sitatokinosi-ichu-number-phpcon-odawara?slide=5
11. かんたんに言うと、MでもCでもないやつら 11 わたしが今回話そうとしているサービス層 気づけばいるやつ / └─ app ├─ Http │ └─ Controllers ├─ Models ├─ Services └─ ... 👈
12. かんたんに言うと、MでもCでもないやつら 12 わたしが今回話そうとしているサービス層 これは何のためにあって🤔 どんなクラスが置かれるべきか知りたい🤔 / └─ app ├─ Http │ └─ Controllers ├─ Models ├─ Services └─ ... 👈
13. かんたんに言うと、MでもCでもないやつら 13 わたしが今回話そうとしているサービス層 これは何のためにあって🤔 どんなクラスが置かれるべきか知りたい🤔 / └─ app ├─ Http │ └─ Controllers ├─ Models ├─ Services └─ ... 👈 そして、アマゾンの 奥地へと向かった
14. 14 アジェンダ 1. サービス層とは何か 2. 憎まれるサービス/愛されるサービス 3. 理想のサービス層 4. まとめ
15. 15 アジェンダ 1. サービス層とは何か 2. 憎まれるサービス/愛されるサービス 3. 理想のサービス層 4. まとめ
16. Q: サービス層とは何か？ 16 わたしの結論
17. A: ぼくの考えた最強の設計 が置かれる場所 17 わたしの結論
18. 18 自分に問うてみた 何のためにサービス層がある？ どんなサービスクラスが必要？ どんなサービスクラスが嫌？
19. 19 わたしの回答 • ◦ 処理フローをひとつに束ねたものを置く場所 ◦ I/O が複数あるものを分離 • ◦ 処理フローがかんたんに呼び出せる ◦ 再利用できるとうれしい • ◦ でかい、if文が多い、過剰に分割されている 何のためにサービス層がある？ どんなサービスクラスが必要？ どんなサービスクラスが嫌？
20. 20 カオナビエンジニア にも聞いてみました
21. 21 みんなに聞いてみたサービス層 そもそも必要だと思いますか？ 　 ケースバイケース - 80% 　 必要だと思う - 20% 　 必要ない - 0% 需要はありそう
22. 22 みんなに聞いてみたサービス層 • ◦ ビジネスロジックの整理、システムの複雑さを管理 ◦ ワークフローを調整・実行する役 • ◦ 複雑な処理（単一のモデルで完結しないなど）を隠蔽 ◦ 再利用されるビジネスロジック ◦ テストが書きやすい • ◦ 過剰分割、肥大、まるで神のような 何のためにサービス層がある？ どんなサービスクラスが必要？ どんなサービスクラスが嫌？
23. 23 わたしの見解 サービス層の役割/目的 • (複雑な)ワークフローを隠蔽 • 再利用したい • テストが書きやすい ものを置くところ
24. サービス層の役割/目的 • (複雑な)ワークフローを隠蔽 • 再利用したい • テストが書きやすい ものを置くところ 24 わたしの見解 設計方針が無
25. サービス層の役割/目的 • (複雑な)ワークフローを隠蔽 • 再利用したい • テストが書きやすい ものを置くところ 25 わたしの見解 ここを色々な 方法で実装して しまう
26. サービス層の役割/目的 • (複雑な)ワークフローを隠蔽 • 再利用したい • テストが書きやすい ものを置くところ 26 わたしの見解 わたしの出会ってきたサービス • DB処理が大量に詰め込まれたサービス • どこからでも呼ばれてしまう「神」 サービス • 取り急ぎ作られた「なんちゃって」 サービス • トランザクションスクリプト（手続 き）がひしめくサービス • 複数のサービスと手を組み、仲良く連 携するサービス • ドメイン層を支えるサービス
27. サービス層の役割/目的 • (複雑な)ワークフローを隠蔽 • 再利用したい • テストが書きやすい ものを置くところ 27 わたしの見解 Q: なぜ人には 人それぞれの サービス層が あるのか
28. サービス層の役割/目的 • (複雑な)ワークフローを隠蔽 • 再利用したい • テストが書きやすい ものを置くところ 28 わたしの見解 A: そこには、 ぼくの考えた 最強の設計が 置かれるから
29. サービス層の役割/目的 • (複雑な)ワークフローを隠蔽 • 再利用したい • テストが書きやすい ものを置くところ 29 わたしの見解 完
30. サービス層の役割/目的 • (複雑な)ワークフローを隠蔽 • 再利用したい • テストが書きやすい ものを置くところ 30 わたしの見解 どんな サービスクラス ならいいのか
31. 1. サービス層とは何か 2. 憎まれるサービス/愛されるサービス 3. 理想のサービス層 4. まとめ 31 アジェンダ
32. 32 💔 憎まれるサービス • 「神」クラス • 手続き、条件分岐が多い • 依存関係が複雑 • 単純すぎてサービスにする必要のないもの
33. 33 💖 愛されるサービス • (複雑な)ワークフローをかんたんに呼び出せるもの • 複数のモデルにまたがる処理が適切に統合されたもの • 再利用性の高いビジネスロジックをまとめたもの • 適度な粒度で責任が明確なもの
34. 💔 DB処理が大量に詰め込まれたサービス 💔 どこからでも呼ばれてしまう「神」サービス 💔 取り急ぎ作られた「なんちゃって」サービス 💔 トランザクションスクリプト（手続き）がひしめくサービス 💖 複数のサービスと手を組み、仲良く連携するサービス 💖 ドメイン層を支えるサービス 34 わたしが出会ってきたサービスを分別
35. // DB触る（SQL書く）やつはとりあえずここへ（昔はよくあった） // EloquentをラップしているRepositoryに似てる class UserService { private \PDO $pdo; public function __construct(\PDO $pdo) { $this->pdo = $pdo; } public function getUserById($id) { /* SELECT処理 */ } public function getAllUsers() { /* SELECT ALL */ } public function createUser($data) { /* INSERT処理 */ } public function updateUser($id, $data) { /* UPDATE処理 */ } public function deleteUser($id) { /* DELETE処理 */ } // 付随したものが増える public function getUsersByCondition($condition) { /* 条件付きSELECT */ } public function existsUser($id) { /* 存在チェック */ } // 以降永遠に続く } 35 💔DB処理が大量に詰め込まれたサービス
36. // ユーザーに関するものならなんでもござれ（xxxManagerとか） class UserService { public function createUser(array $data) { … } public function updateUser($id, array $data) { … } public function deleteUser($userId) { … } public function validateUser(array $data) { … } public function sendWelcomeEmail($user) { … } public function generateReport($userId) { … } public function exportUserData($userId) { … } // ... さらに続く } 36 💔どこからでも呼ばれてしまう「神」サービス
37. // とりあえずXXXサービスというところに書く // EloquentをラップしているRepositoryに似てる class UserService { // 何かやっていそうで何もやっていない // Pass-through public function find($id) { return User::find($id); } } 37 💔取り急ぎ作られた「なんちゃって」サービス
38. class OrderService { public function processOrder(array $orderData) { // 100行以上の処理が続く... if ($orderData['type'] === 'premium') { if ($orderData['amount'] > 10000) { // 処理A if ( … ) { // 処理B // さらに処理が続く... } else { … } } } else if (...) { … } // まだまだ続く... } } 38 💔憎まれるサービスの代表例 (トランザクションスクリプト（手続き）がひしめくサービス)
39. 39 💔憎まれるサービスの代表例 (トランザクションスクリプト（手続き）がひしめくサービス) • 手続き的な処理がダラダラと続く ◦ メソッドが異常に長い • 条件分岐が複雑に絡み合う ◦ 変更時の影響範囲が読めない • テストを書くのが困難 • 一つのクラスがいろいろな責務を持っている
40. // 注文処理の複雑さを隠蔽 → 複雑な業務フローの隠蔽 final class OrderProcessingService { public function __construct( private PaymentGatwayInterface $payment, private InventoryService $inventory, private ShippingService $shipping ) {} public function processOrder(OrderRequest $req): Order { return DB::transaction(function () use ($req) { // 在庫確認 $this->inventory->reserve($req->items); // 決済処理 $payment = $this->payment->charge($req->paymentMethod, $req->amount); // 配送手配 $shipping = $this->shipping->arrange($req->shippingAddress, $req->items); // 注文作成 $order = Order::create([ 'user_id' => $req->userId, 'payment_id' => $payment->id, 'shipping_id' => $shipping->id, 'total_amount' => $req->amount, ]); return $order; }); } } 40 💖愛されるサービスの代表例 (複数のサービスと手を組み、仲良く連携するサービス)
41. 41 💖愛されるサービスの代表例 (複数のサービスと手を組み、仲良く連携するサービス) • 責務が分離されている ◦ 各責務（在庫・決済・配送）を別のクラスに委譲 ◦ OrderProcessingService は全体の調整役に徹している • 処理の流れが明確 ◦ 在庫確認→決済→配送→注文作成 • 依存性注入（DI）の適切な利用 ◦ 決済方法を変更したい場合は PaymentGatewayInterface の実 装だけを変更すれば済む
42. 通称：PofEAA • 9章に Service Layer のことが 書かれている 42 賢者の考えるサービス層 Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler))
43. サービスレイヤー 3行まとめ 1. アプリケーションの「受付窓口」 2. 処理の流れ(アプリケーションロジック)を調整 し、ドメインロジックは別の層に任せる 3. 複数の入り口(Web、API等)での重複処理をな くす 43 賢者の考えるサービス層 Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler))
44. サービスレイヤー 3行まとめ 1. アプリケーションの「受付窓口」 2. 処理の流れ(アプリケーションロジック)を調整 し、ドメインロジックは別の層に任せる 3. 複数の入り口(Web、API等)での重複処理をな くす 44 賢者の考えるサービス層 Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler)) 愛されるサービス なんとなく合っている
45. 通称：APoSD • 4.4 深いモジュール （Deep Module） • この考えも取り入れられる 45 賢者の考えを拝借 A Philosophy of Software Design, 2nd Edition
46. 46 賢者の考えを拝借 A Philosophy of Software Design, 2nd Edition 深いモジュール と 浅いモジュール （インタフェースは小さくて、機能は多いものがよいを表す図）
47. • 深いモジュール（利用者に優しい） ◦ シンプルなインターフェース ◦ 強力な機能 ◦ 複雑性を隠蔽 • 浅いモジュール（利用者が苦労） ◦ 複雑なインターフェース ◦ 薄い機能しか提供していない ◦ 複雑性が漏れる → 多くのメソッドが露出 47 賢者の考えを拝借 A Philosophy of Software Design, 2nd Edition
48. • 深いモジュールの考えをサービス層へ ◦ シンプルなインターフェースで複雑なワーク フローを実行 ◦ 利用者は内部の複雑さを知る必要がない ◦ 「浅いモジュール」の対極を目指す 48 賢者の考えを拝借 A Philosophy of Software Design, 2nd Edition
49. 1. サービス層とは何か 2. 憎まれるサービス/愛されるサービス 3. 理想のサービス層 4. まとめ 49 アジェンダ
50. 50 Facade サービス層 is ファサード（Not Laravel） 1. 受付窓口 2. 処理の流れを調整 増補改訂版Java言語で学ぶデザインパターン入門 15章を読もう
51. 51 SOLID原則のS（Single Responsibility Principle） サービス層 is 責務が大事 1. 窓口として一つのことをうまくやる 2. ファサードの中で使うクラスも責務は一つ
52. 52 SOLID原則のS（Single Responsibility Principle） 単一責任原則 • モジュールはたったひとりのユーザーやステークホルダーに対して責 務を負うべきである • モジュールを変更する理由はたったひとつだけであるべきである • モジュールはたったひとつのアクターに対して責務を負うべきである
53. 53 SOLID原則のS（Single Responsibility Principle） 詳しくはこの本（9章）を読んでみよう
54. // 注文処理の複雑さを隠蔽 → 複雑な業務フローの隠蔽 final class OrderProcessingService { public function __construct( private PaymentGatwayInterface $payment, private InventoryService $inventory, private ShippingService $shipping ) {} public function processOrder(OrderRequest $req): Order { return DB::transaction(function () use ($req) { // 在庫確認 $this->inventory->reserve($req->items); // 決済処理 $payment = $this->payment->charge($req->paymentMethod, $req->amount); // 配送手配 $shipping = $this->shipping->arrange($req->shippingAddress, $req->items); // 注文作成 $order = Order::create([ 'user_id' => $req->userId, 'payment_id' => $payment->id, 'shipping_id' => $shipping->id, 'total_amount' => $req->amount, ]); return $order; }); } } 54 【再掲】複数のサービスと手を組み、仲良く連携するサービス
55. 55 クラス図で見てみる by smeghead/php-class-diagram
56. 56 注文処理を行うことに責任を持つ 窓口は一つ 責務は一つ
57. 57 内部の複雑さを隠蔽 シンプルなイン ターフェースで 複雑な処理を 実行
58. 58 利用者は内部の複雑さを知る必要がない 利用者に優しい
59. 59 シンプルなインターフェースは使いやすい 言うならば ここも一緒
60. 60 テスタビリティが高い 分離しているの でテストも書き やすい
61. 61 変更による影響を受けないように 変わるものは 抽象に依存
62. 62 窓口から覗いたらその依存関係の多さにギョッとなったことあると思います 複雑な依存関係 を持ち込まない
63. 63 クラス症候群を避ける（APoSD 4.6） 単一責務にこだ わるとなりがち
64. 64 品質を測る3つの指標 1. 循環的複雑度（Cyclomatic Complexity） ◦ 条件分岐の複雑さを示す指標 ◦ 理想値: 10以下 2. 結合度（Coupling） ◦ モジュール間の依存関係の強さ ◦ 理想: 疎結合 3. 凝集度（Cohesion） ◦ モジュール内の要素の関連性の強さ ◦ 理想: 高凝集 PhpMetrics などで計測可能 https://github.com/phpmetrics/PhpMetrics
65. final class OrderProcessingService { public function __construct() {} public function processOrder(OrderRequest $req): Order { return DB::transaction(function () use ($req) { // 在庫確認 $this->inventoryReserve(...); // 決済処理 $payment = $this->paymentCharge(...); // 配送手配 $shipping = $this->shippingArrange(...); // 注文作成 $order = Order::create(...); return $order; }); } private function inventoryReserve(...) { /* 在庫を管理するロジック*/ } private function paymentCharge(...) { /* 決済を行うロジック */ } private function shippingArrange(...) { /* 配送を手配するロジック*/ } } 65 初手のFatを恐れない 初手のFatを 恐れない
66. final class OrderProcessingService { public function __construct() {} public function processOrder(OrderRequest $req): Order { return DB::transaction(function () use ($req) { // 在庫確認 $this->inventoryReserve(...); // 決済処理 $payment = $this->paymentCharge(...); // 配送手配 $shipping = $this->shippingArrange(...); // 注文作成 $order = Order::create(...); return $order; }); } private function inventoryReserve(...) { /* 在庫を管理するロジック*/ } private function paymentCharge(...) { /* 決済を行うロジック */ } private function shippingArrange(...) { /* 配送を手配するロジック*/ } } 66 最初は大胆に、そして少しずつ整理でも (なんなら) 最初は コントローラー ↓ 複雑、責務が入り混 じってきたら ↓ サービス （責務を分離）
67. class OrderService { public function processOrder(array $orderData) { // 100行以上の処理が続く... if ($orderData['type'] === 'premium') { if ($orderData['amount'] > 10000) { // 処理A if ( … ) { // 処理B // さらに処理が続く... } else { … } } } else if (...) { … } // まだまだ続く... } } 67 【再掲】トランザクションスクリプト（手続き）がひしめくサービス 窓口は一つ これでもいいの では？
68. class OrderService { public function processOrder(array $orderData) { // 100行以上の処理が続く... if ($orderData['type'] === 'premium') { if ($orderData['amount'] > 10000) { // 処理A if ( … ) { // 処理B // さらに処理が続く... } else { … } } } else if (...) { … } // まだまだ続く... } } 68 みんなで仲良く メンテナー にも優しくあれ
69. サービスクラス、いつ必要？ • 同じ処理を異なるエントリポイ ントから使えるように実装した いとき サービスクラスに何を書く？ • エントリポイント固有の差異を 除いた共通の操作のみ 69 なんやかんや言いましたが サービスクラスのありがたみを発見したときの思い出 #phpcon_odawara（本日2回目の登場）
70. 1. サービス層とは何か 2. 憎まれるサービス層/愛されるサービス層 3. 理想のサービス層はあるのか 4. まとめ 70 アジェンダ
71. 結論 みんな違ってみんないい 71 まとめ
72. 結論 みんな違ってみんないい 72 まとめ
73. みんな違うからこそ 考えを揃える事が大事 73 まとめ
74. 例えばチームでこんな基準を設ける □ 単一責任になっているか □ シンプルなインターフェースか □ 依存関係が追跡可能か □ 循環的複雑度が10以下か（感覚ではなく計測する） □ このサービスの必要性に全員が納得しているか 74 まとめ
75. 例えば自分に対して問うてみる □ このサービスは何をするもの？ に一言で答えられるか □ なぜサービス層に切り出したの？ に明確に答えられるか □ 明日の自分が見ても理解できるか □ 他のチームメンバーが拡張しやすいか 75 まとめ
76. 自分の考えと チームの考えを揃える 76 まとめ
77. 設計方針を揃える 77 まとめ
78. 揃えて終わりではなく 改善、育てていく 78 まとめ
79. わたしが思うサービス層とは ”チームで磨いた設計原則を 体現するレイヤー” 79 まとめ
80. Appendix 80
81. 81 みんなに聞いてみたサービス層 1. たくさんの質問をみんなへ 2. 質問を以下でグルーピング a. 質問1: サービス層とは何か？その役割は？ b. 質問2: サービス層はいつ必要？ c. 質問3: サービス層の良い点と悪い点は？ 3. 回答をまとめたものが、この後ツラツラと続きます
82. 82 みんなに聞いてみたサービス層 質問1: サービス層とは何か？その役割は？ • ビジネスロジックの実装場所 ◦ 「ビジネスロジックやワークフローを調整・実行する役」 ◦ 「ビジネスロジックの計算を担当し、基本的には外部システムに依存しない層」 ◦ 「サービス層はビジネスロジックを持つもの、もっと言うと、インターフェース を実装するもの」 ◦ 「端的に言えば、ビジネスロジックをカプセル化するところ」
83. 83 みんなに聞いてみたサービス層 質問1: サービス層とは何か？その役割は？ • 複数のレイヤー・ドメイン間の連携役 ◦ 「FatControllerになるのも嫌だし、FatModelになるのも嫌だし、複数のテーブ ルにまたがるような処理(特にActiveRecordパターンの場合)はどこに置けばいい のかわからない。そんな処理の塊をいい感じに押し込めるためのサービス層。」 ◦ 「Domain、ApplicationService、Infrastructureなど、各レイヤーそれぞれに存 在している橋渡しや調整を担う役割の総称」 ◦ 「ドメイン知識を持っていて、複数ユースケースに跨り何かの処理を実行してく れる」
84. 84 みんなに聞いてみたサービス層 質問1: サービス層とは何か？その役割は？ • その他見解 ◦ 「MVCで言うところの、どれでもない奴」 ◦ 「１ファイルに長々と処理を書いている時に、処理を分割するためにサービスっ てとこに書く感じかな」 ◦ 「使い回し可能な業務仕様置き場」 ◦ 「そんな腑抜けた名前の層はない。アプリケーションが先でレイヤリングは後で しょう。」 👀
85. 85 みんなに聞いてみたサービス層 質問2: サービス層はいつ必要？ • 複雑さ・規模に応じて判断 ◦ 「コントローラーで書く処理が複雑になったら」 ◦ 「処理の規模が大きくないうちは使わず、Controllerが肥大化したら検討する」 ◦ 「AIが読むのが辛くなってきたら（500行くらい）」 ◦ 「複雑な挙動でない場合は、いらない場合もあるかも」 ◦ 「サービス層は必要になるまで作らなくていいと思う」
86. 86 みんなに聞いてみたサービス層 質問2: サービス層はいつ必要？ • 共通処理・再利用性により判断 ◦ 「コードが重複し、分割する必要があれば初めて使っている」 ◦ 「色んなところで共通で使いたい処理がでてきたら、サービス層に押し込めばい いと思う」 ◦ 「複数ユースケースにまたがる処理を書きたい場合」 ◦ 「共通業務仕様であれば」
87. 87 みんなに聞いてみたサービス層 質問3: サービス層の良い点と悪い点は？ • 可読性・理解しやすさ ◦ 「サービス層を見たらワークフローがわかるのが最高だと思っている」 ◦ 「APIが何をするのか？を見る際にサービス層以外を見る必要がなくなった」 ◦ 「どこに何があるかがわかる」
88. 88 みんなに聞いてみたサービス層 質問3: サービス層の良い点と悪い点は？ • テスト容易性・保守性 ◦ 「ビジネスロジックのテストが容易である点。その他の汎化可能なロジックをラ イブラリとして切り出しやすくなる点。」 ◦ 「HTTPのRequestに依存せずにテストが書ける」 ◦ 「手続きとルールを分離できるのでテストコードが書きやすい」 ◦ 「細かいケースのUTを書いても実行速度に影響をそんなに与えない（通常な ら）」
89. 89 みんなに聞いてみたサービス層 質問3: サービス層の良い点と悪い点は？ • 過剰分割・肥大化のリスク ◦ 「サービス層以外も切りすぎて理解が出来なくなった時」 ◦ 「クラスが多すぎて管理が大変になったとき」 ◦ 「一つのサービスクラスが大きくなりがちで、なんでもできちゃうサービスクラ スが生まれたこと」 ◦ 「名前が抽象的すぎてなんでも入ってるみたいな状態（つまり神クラス）」
90. 90 みんなに聞いてみたサービス層 その他のご意見 • 「細かく切ることが正義じゃないと思う」 • 「人によって呼び名は変わる」 • 「そもそもサービスオブジェクトとアプリケーションサービスとドメ インサービスの違いもよくわからない・・・」 • 「Repository というよく分からんデータアクセス層とORMを操る ソースコードとユースケースと言われるものが入り乱れたゴミ箱」 • 「先に層を語るやつは、何をやらせてもだめ」 💣 💣
91. • Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler)) ◦ https://www.amazon.co.jp/dp/B008OHVDFM • A Philosophy of Software Design, 2nd Edition ◦ https://www.amazon.co.jp/dp/B09B8LFKQL • 増補改訂版Java言語で学ぶデザインパターン入門 ◦ https://www.amazon.co.jp/dp/4797327030 • サービスクラスのありがたみを発見したときの思い出 ◦ https://speakerdeck.com/77web/sabisukurasunoarigatamiwofa-jian-sitato kinosi-ichu-number-phpcon-odawara 91 参考資料
92. ご清聴ありがとうございました 92