classの責務について考えてみた

こんにちは、エンジニアになり１年が経ちました。

現在はバックエンド〜インフラまでの領域に従事しています。(フロントもやったりする)

僕が所属している会社ではバックエンドはlaravelを採用しています。最近はバックエンドのタスクに従事しており、日々勉強になっています。

所属会社の採用アーキテクチャーとして軽量DDD(？？)を採用しております。

そんなアーキテクチャの中でrepositoryパターンでqueryを作成した時に感じたことをブログに残しておこうと思います。

repositoryを採用するメリットとしては責務を分けることで、保守性を担保でき、また集約の中でinterfaceを定義することで集約ベースで明示的にメソッドを強制させ実装に対して制約を持たせることで一貫性を持たせることができると考えております。

集約というワードが出てきましたが、残念ながら弊社ではモデリングの部分を行なっていない為、laravelのmodelベースでrepositoryが分割されております。

そいった背景を踏まえて、modelベースでrepositoryを実装した時にあることを感じました。

それはlaravelの機能にscopeというmodelの機能を使用した時です。

先に話しておきますとscopeという機能は特定のModelクラスの中でscopeHogeHogeとメソッドを追加し引数にBuilderインスタンス、任意の引数を受け取り、ORMがかけちゃったりします。


public function scopeHoge(Builder $query, int $int)
{
    return $query->where('id', $int);
}

こんな記述です。今回行ったのが検索ボックスから検索queryを作成していた時に、ドキュメントを見ていたら、こんな機能があるな~ 思い記述してみました。

よしよし期待通りの動きをしていると、噛み締めながら実感していたところ、ある事に気づきました。

これmodelの中身をパッとみたときに、なんの為に実装したメソッドか分からなくない？？そしてこんなものを増やしていったら、model肥大しない？？

保守性を考慮するとrepositoryの関心ごとがmodelに漏れ出している事に気づきました。

実際この機能自体あまり使うところがないかもですが、この実装はやめました。

frameworkが提供してくれる機能は便利なものが多いです。ですが今回見てたく、なぜrepository層として分けているのか、クラスの責務とは？？を考えながら実装していく必要がある事に再度気がつかせてくれました。

最近ではDDDの勉強を個人で行なっています！！！

下記は、早く読んでおけば良かった本を掲載しておきます。

ではまた〜