ServiceとRepository - Speaker Deck

Slide 1

Slide 1 text

PHP勉強会 ServiceとRepository

Slide 2

Slide 2 text

自己紹介ショウノシオリ ○ 株式会社chatbox ○ エンジニア ○ @shoshoでQiita記事書いてます ○ Laravel と日々格闘

Slide 3

Slide 3 text

最近開発したもので出てきた Service と Repository がよくわからなかったので勉強してみました

Slide 4

Slide 4 text

開発したもの ▷ Laravel 5.4 ▷ ECサイト（管理画面のみ） ▷ フロントは他の会社 ▷ コードの設計は完了済みだった

Slide 5

Slide 5 text

開発に使う主なもの ▷ View ▷ Route ▷ Controller

Slide 6

Slide 6 text

と ▷ Service ▷ Repository ▷ Eloquent

Slide 7

Slide 7 text

DBにアクセスするまでの流れ Controller Service Repository Eloquent DB

Slide 8

Slide 8 text

DBまわりがなぜこんなに細かく分けられているんだろう？

Slide 9

Slide 9 text

Service と Repository は必要なのか？

Slide 10

Slide 10 text

DBにアクセスするまでの流れが Controller Service Repository Eloquent DB だとすると

Slide 11

Slide 11 text

２つの問題点 ▷ DBの設計が変わったときに、　Eloquentを使っているコントローラ全てを修正する必要が出て来る ○ めんどう ○ 大変 ▷ フロントでも同じDB操作をすることがあるのに、別々でつくるのはもったいない ○ ユーザー情報の取得、とか

Slide 12

Slide 12 text

この２つを解決するのが Service と Repository

Slide 13

Slide 13 text

DBの設計が変わったときに、Eloquentを使っているコントローラ全てを修正する必要が出て来る問題

Slide 14

Slide 14 text

Repositoryが解決 ▷ Eloquentを操作する唯一のクラス。ここから先はEloquentではなくEntityとしてデータを持ち回すようにしている。 ○ DB変更に伴うEloquentの修正が与える影響はリポジトリ内に収まる ○ 修正箇所を見つけやすい ○ 修正する場所も少なくて済む

Slide 15

Slide 15 text

フロントでも同じDB操作をすることがあるのに、別々でつくるのはもったいない問題

Slide 16

Slide 16 text

Serviceが解決 ▷ 「ユーザー情報を取得したい」といった具体的な要求に対する処理を提供するクラス。 ○ 再利用できる ○ 処理自体を固めることになるので、画面の仕様変更などに強くなる

Slide 17

Slide 17 text

なので以下のような役割分担になっているのかな、と

Slide 18

Slide 18 text

Controller Service Repository Eloquent DB リクエストの受取と結果を返す、だけ要求に対するものを提供するクラス Eloquentを管理する唯一のクラス DBを操作する

Slide 19

Slide 19 text

このように関心事 = ドメインを中心に開発をすすめる方法がドメイン駆動設計（DDD）的な？

Slide 20

Slide 20 text

なぜこんなに細かくわけられているんだろう？の答えとしては

Slide 21

Slide 21 text

▷ フロントとの開発をみこしたものだから ▷ 各クラスにしっかり役割分担しておくことで修正しやすくするためかなぁと思いました

Slide 22

Slide 22 text

つくる立場であっても少しずつ設計思想についても学んでいきたいと思います

Slide 23

Slide 23 text

Thanks! Any questions?