More than 5 years have passed since last update.

Railsのファットモデル問題に対処する前に読んでほしい記事

Last updated at 2018-01-23Posted at 2018-01-22

背景

Skinny Controller, Fat Model

Railsではスキニーコントローラー、ファットモデル（Skinny Controller, Fat Model）という方針のもと、
コントローラーのコード量を少なくして、モデルを分厚くするという書き方が推奨されていました。

10 Ruby on Rails Best Practices — SitePoint
Rails Best Practices 1: Fat Model – Skinny Controller

このような背景から、ファットモデルという設計が目指すべき設計という認識となりました。

「ファットモデル問題」の登場

ところが、原因はわかりませんが、次第にファットモデルが問題があるものとしてみられるようになりました。
界隈では「ファットモデル問題」として取り上げて解決するという方法が紹介されるようになります。

2012年の英語の記事が全ての始まりらしいです。
7 Patterns to Refactor Fat ActiveRecord Models

それを日本語で解説した記事が投稿されて広まったのかもしれません
肥大化したActiveRecordモデルをリファクタリングする7つの方法（翻訳）

これらの記事で言われていることは

ActiveModelを分割して、責任を小さいオブジェクトに分ける
- サービスクラス、フォームクラス等

というものです

この考え方に影響を受けて、2013~2015の時期は色々な方法が編み出されたようです。

多くの記事では

オブジェクト指向
ドメイン駆動設計

を用いてActiveModelを分割の方法を提案していました。

ActiveModelを分割が難しいという問題

提案された方法ではフォームクラス、バリデータークラス、サービスクラスなどが提案されました。
なかでもサービスクラスと言うものが有名になり、多くのプロジェクトにたくさん導入されました。
憶測なのですが、サービスという言葉が日本人に誤解を生みやすい（サービス残業、レディースサービス等）ので、使われたのかもしれません。
FormやValidatorはよくわからないけど、Serviceだったら理解できるという心境だったのでしょう。

※　私も当時、モデルにロジックを書かないような設計を教えられました。なので当時から保守を行っているようなアプリにはサービスクラスが導入されています。

結果から言うと、多くの人が提案した「ActiveModelを分割」はほとんど失敗だったと思います。

オブジェクト指向、ドメイン駆動設計などを取り上げて提案していましたが、殆どの人には理解されず

悪いコードを分離させて切り出すためのクラス
単にコード量を減らすため

といった方法で使われたのがほとんどだと思います。
私のところでは、悪いコードの避難所としてサービスクラスなどのオブジェクトが使われたため、有効に使えたプロジェクトは少なかったのでは無いでしょうか。

そのような状況だったので2016年には**「ActiveModelを分割」は失敗だった**という記事が多く書かれました。

なぜ失敗したかは以下のような理由だと思います

責任の分離の設計や考え方に個人差があり、統一できずに無秩序になってしまった
- 同じRailsなのに書き方がぜんぜん違うという現象
「ActiveModelを分割」という考え方自体がRailsの思想と離れているので、バージョンアップが大変
方法は素晴らしいが、実際にやってみると簡単ではなかった

ファットモデル問題とは

ここで改めてファットモデル問題についてまとめます。

ファットモデルは目指すべきものなので、ファットモデル自体が問題ではない
- モデルに書くべきでない処理を書くということが問題
- モデルに書くべき処理によってコード量が多いのであれば、それは問題ではない
仕方なく肥大化してしまったときに「ActiveModelを分割」という方法が提案された
- 下手に分割をしてしまって負債を生む結果となってしまった