ServiceとRepository

2017/4/12 関西PHPユーザーズグループの勉強会での登壇資料です。

ServiceとRepositoryについて自分なりに解釈してみたことをまとめました。

Transcript

1. PHP勉強会 ServiceとRepository
2. 自己紹介 ショウノシオリ ◦ 株式会社chatbox ◦ エンジニア ◦ @shoshoでQiita記事 書いてます ◦ Laravel と日々格闘
3. 最近開発したもので出てきた Service と Repository がよくわからなかったので勉強してみました
4. 開発したもの ▷ Laravel 5.4 ▷ ECサイト（管理画面のみ） ▷ フロントは他の会社 ▷ コードの設計は完了済みだった
5. 開発に使う主なもの ▷ View ▷ Route ▷ Controller
6. と ▷ Service ▷ Repository ▷ Eloquent
7. DBにアクセスするまでの流れ Controller Service Repository Eloquent DB
8. DBまわりがなぜ こんなに細かく分けられているんだろう？
9. Service と Repository は必要なのか？
10. DBにアクセスするまでの流れが Controller Service Repository Eloquent DB だとすると
11. ２つの問題点 ▷ DBの設計が変わったときに、　Eloquentを 使っているコントローラ全てを修正する必要 が出て来る ◦ めんどう ◦ 大変 ▷ フロントでも同じDB操作をすることがある のに、別々でつくるのはもったいない ◦ ユーザー情報の取得、とか
12. この２つを解決するのが Service と Repository
13. DBの設計が変わったときに、Eloquentを使っ ているコントローラ全てを修正する必要が出て 来る 問題
14. Repositoryが解決 ▷ Eloquentを操作する唯一のクラス。ここか ら先はEloquentではなくEntityとしてデータ を持ち回すようにしている。 ◦ DB変更に伴うEloquentの修正が与える 影響はリポジトリ内に収まる ◦ 修正箇所を見つけやすい ◦ 修正する場所も少なくて済む
15. フロントでも同じDB操作をすることがあるの に、別々でつくるのはもったいない 問題
16. Serviceが解決 ▷ 「ユーザー情報を取得したい」といった具体 的な要求に対する処理を提供するクラス。 ◦ 再利用できる ◦ 処理自体を固めることになるので、画面 の仕様変更などに強くなる
17. なので以下のような役割分担になっている のかな、と
18. Controller Service Repository Eloquent DB リクエストの受取と 結果を返す、だけ 要求に対するものを 提供するクラス Eloquentを管理する 唯一のクラス DBを操作する
19. このように 関心事 = ドメイン を中心に開発をすすめる方法が ドメイン駆動設計（DDD） 的な？
20. なぜこんなに細かくわけられているんだろう？ の答えとしては
21. ▷ フロントとの開発をみこしたものだから ▷ 各クラスにしっかり役割分担しておくことで 修正しやすくするため かなぁと思いました
22. つくる立場であっても 少しずつ設計思想についても学んでいきたいと 思います
23. Thanks! Any questions?