melank Table of Contents
チームLIGHTの紹介
チームLIGHTは現在エンジニア5名、デザイナー2名の合計7人のチームです。 チームLIGHTの雑記ブログもありますので、よかったらそちらもどうぞ！ こちらは技術的な内容ではなく、メンバーの日常のことをつらつらと書いています。
また、不定期でLIGHT@NOONという配信イベントも開催しています。
Laravel輪読会の紹介
チームLIGHTでは、週に1回1時間、Laravel輪読会を実施しています。
輪読会で読む本はこちらの本です！
www.amazon.co.jp
2021/6/1に発売されたばかりの本で、Laravel8にも対応しています。
ボリュームもたっぷりな上に、Laravelの設計やテストコードに関する内容も充実しているので、オススメです！
本題
今回読んだページは P.213 ~ P.222 の「5-5 リポジトリパターン」についてです。
5-5-1 リポジトリパターンの概要
リポジトリパターンは、ビジネスロジックとデータアクセスのロジックを分離し、データ操作を抽象化したレイヤに任せるデザインパターンです。 ある程度の規模かつ長期運用の見込めるシステムなどに適用することで、コードのメンテナンス性やテストの容易性を高めることができます。
5-5-2 リポジトリパターンの実装
出版社テーブル publishers に出版社を追加する API を
Publisherモデル- ビジネスロジックを詰めた
PublisherServiceクラス - コントローラである
PublisherActionクラス という構成で実装しています（具体的なコードは割愛します）。 そして、api/publishersというエンドポイントで待ち受けるようにします。
Route::post('publishers', [PublisherAction::class], 'create');
上記エンドポイントに対して POST でリクエストを投げると、出版社が新規作成されるような動作イメージです。
5-5-3 リファクタリング
5-5-2 で紹介した API は、PublisherService 内で Eloquent である特定の具象クラスを参照することで、データストアの選択に対して柔軟ではない実装になっていました。もし他のデータストアやキャッシュ、テスト用のモックなどを使用する場合などにこの部分のコードは大きく変更する必要がある設計になっています。 本章はそれらに対して、リファクタリングを実践する章です。リファクタリングされた内容は、下記のようなものになります。
- RepositoryInterface を新たに実装
- Service クラス内で Interface を注入することにより、Repository が変更されたとしても、同じ Interface を持っていれば動作可能となる
- Publisher の Entity クラスを新たに実装
- データアクセス層が Repository と切り離される
- Interface と 具象クラスを紐付ける
チームで話したこと
- やるならプロジェクト内で一貫してやらないと。部分的に採用するのはよくない
- RepositoryInterface のディレクトリというか namespace に悩む
- そもそも DB 周りが差し替わる可能性のあるような案件やったことないな
本参考書上でも、少しずつ具体的なコードを書く段階に入ってきた感じがしています。
次回からは、大事な「認証・認可」のセクションに入っていきます。
ありがとうございました。
melank
Engineer ✨ PHP ( Laravel, CakePHP ) 🐘 AWS ( 🏆 DBS, SCS, SAA, DVA, SOA )
