More than 3 years have passed since last update.

Railsと上手く付き合っていく方法

Posted at 2020-12-31

何これ

今居る会社のメンバーはあまりRailsに慣れてなく、自分に質問が結構来るので社内向けwikiにまとめていた。
評判よかったのでせっかくなのでQiitaにも投稿。

個人的な思想も含まれてるので過信禁物。

必要になったら必要な分だけ導入する。

アーキテクチャ

Presenter

viewのために、データを用意する
controllerに記述してしまうとfatになってしまいがちなviewの特異的なロジック等を記述する

viewと1:1
イメージ的にはviewのためにデータを用意したりするために使う
基本的にpresenterに全部持たせて、controllerはpresenterを生成するだけにし、viewはpresenterから必要な値などを利用する
例: 画面上のオススメ記事一覧のためにrecommend_articles を用意したい

Decorator

modelのために、modelをデコレーションする
modelに記述してしまうとfatになってしまいがちなメソッドを記述する

modelと1:1
イメージ的にはアプリケーション全体で整形後のmodelの値を使いたいときに使う
例: modelのlast_name と first_name を last_name + first_name として使いたいので full_name メソッドを定義する

Finder

複雑になりがちな検索クエリを生成する
modelに記述してしまうとfatになったり、スパゲッティ化してしまうクエリを記述する

友人がいい感じに実装してたので詳しくは以下
https://furaji.hatenablog.jp/entry/2020/05/09/043924

Service

複数model間にまたがる処理など、単一のmodelに書きづらい処理を記述する

基本的に単一責務でいきたいので、 動詞 + 対象 + Service といった名前にする
例: ユーザー生成時にUser modelだけでなく複数のmodelにまたがった処理をするので CreateUserService を作る
使う側はできるだけServiceに関与しない
例: CreateUserService.call(args) で使う側は完結したい

ValueObject

オブジェクト(特にmodel)の値を値ではなくオブジェクトにすることにより、値に対する責務をもたせる。
- ActiveRecordなら composed_of が使えるので楽
- 例: user.address の address を ValueObjectとしてクラスを分割すれば、User modelを汚すことなく、 address にのみ関心がある処理を書くことができる。 user.address.tokyo? など
- Decoratorがmodel全体に関心があるのであれば、ValueObjectはmodel内の一つの値に関心がある

説明しづらいので丸投げ
https://qiita.com/okuramasafumi/items/16bcda8f6382a3db47c9