行き着いた背景
Laravel、MVCだけの取り決めだと、書く人によってFatControllerになってたりFatModelになったりする。
これってどうにかならないの？と思い、Repositoryパターンもどきを実践してみた。
やった事
大まかな役割を持たせた層を用意し、開発ルールを設けた。
層
以下の階層に分ける
- LivewireComponent/Controller
- Service
- Repository
- Model
参照関係
LivewireComponent/Controller
- ビジネスロジックは書かない
- アクセス可能な他の層はServiceのみ※Modelオブジェクトの定義は良い
- 単純にデータが欲しいだけの時も必ずServiceを仲介する
Service
- ビジネスロジックは全てここに書く
- DB操作ロジックは書かない
- アクセス可能な層はRepository層のみ
- 極力他のServiceを呼び出さないようにする※共通処理はTraitにまとめれそうならまとめる
Repository
- DB操作のロジックは全てここに書く
- 関連が強いModelの処理を集約させる
- Userモデル、UserImageモデル、UserPostモデルなどUserに紐づく情報は全てUserRepositoryに集約させる
Model
- リレーションの定義や、属性の定義のみ書く
課題
- Serviceクラスの切り分けが少し悩む
- 現状Serviceクラスに全てのロジックを入れている為、単純な処理置き場になっている
- ServiceからServiceへのアクセスをルールとして許している場合、改修する時に考えるべき影響範囲が増える
- もう一つ層を挟むにしても、自分が取り扱うプロジェクト的にはオーバースペックな気もする
取り入れた感想
- どの層に何を書くかが明確になった為、切り分けがしやすくなった
- ルールを設けたので書く人によってのムラが少なくなった
- まだ開発途中だが、処理が色んな所にとっちらかないので改修などがしやすい。
- MVCのみで開発してきた人でもとっつきやすいので、脱MVCの第一歩に良さそう。
参考記事