Fat Model問題を説明してみましょう。 ここでいうFat Model問題とはRuby on Raisを使って書かれたWebアプリケーションにおいてモデルクラスが大きくなりすぎる問題のことをいいます。 Ruby on Railsでは、MVC（model-view-controller）というアーキテクチャパターンを採用しています。
ブラウザがRailsアプリと通信する際、一般的にWebサーバーにリクエスト（request）を送信し、これはリクエストを処理する役割を担っているRailsのコントローラ（controller）に渡されます。コントローラは（ユーザーなどの）サイトの要素を表しており、データベースとの通信を担当しているRubyのオブジェクトであるモデル（model） と対話します。モデルを呼び出した後、コントローラは、ビューを描画し、完成したWebページをHTMLとしてブラウザに返します。
Ruby on Railsではコントローラーには処理をほとんど書かずに、モデルクラスの呼び出しのみを書くべきだとされています（要出展）。 例えば、DHHが示したBasecamp3というアプリケーションの統計情報では、コントローラーのメソッド辺りの行数（LOC/M）は3行しかありません。
Basecamp 3 is up to 308 controllers. Some 1400 methods. Imagine recreating all that with all-native apps? No thanks. Majestic be thy Monolith. pic.twitter.com/aTmwGT32ep
— DHH (@dhh) February 9, 2018
では処理はどこに書くのでしょうか？MVCの残りの登場人物はモデルクラスとビューです。 MVCはPresentation Domain Separation (PDS)原則に則っています。 ビューにはプレゼンテーション（見た目の整える）処理のみを書きそれ以外の処理はモデルに書きます。 つまり、見た目に関わらないほとんどの処理はモデルクラスに書きます。
この方針のまま大きなアプリケーションを実装したらどうなるでしょうか？ 大きなモデルクラスが誕生します。 モデルクラスが大きくなると変更が難しくなります（なぜ？）。 これがFat Model問題です。
で、DHHのツイートを見なおしてみましょう。 モデルクラスは2万行近くあって300個以上あります。 が、クラス辺りのメソッド数（M/C）は8しかないしメソッド辺りの行数は3なんですよね・・・どこがFatなのか？ ServiceクラスもFormオブジェクトも使わなくともFat Model問題は起きないみたいですよ？どういうことですか？
参考
- rails アプリの統計情報を一発で取れる rake stats を試した - clayfishの日記
- プレゼンテーションとドメインの分離
- rails アプリの統計情報を一発で取れる rake stats を試した - clayfishの日記
- 改めて振り返る Fat Controller / Fat modelとの戦い - masa寿司の日記
- Fat Modelの倒し方 / how to deal with fat model - Speaker Deck
20220317追記
texta.fmの第7回「Fat Controllers and Models」を公開しました！ - てくすた を聞きました。
- コントローラーの方がテストを書きにくいので、Fat Controller vs Fat ModelならばFat Modelがまし
- Fat Modelになるのはデータモデリングが出来ていないため。テーブルが少ない。典型的にはテーブルが、リソースのみでイベントエンティティがない。
- クラスメソッドが多いのは悪いコードの匂い。特にモデルクラスから別のモデルクラスのクラスメソッドを呼んでいるのは良くない。
つづいて 本ブログのポッドキャスト「texta.fm」を始めました！ - てくすた の3. Low-Code Developmentも聞きました。 半分寝落ちしてましたが、「URL設計とデータ設計が上手くできればRailsは高速開発できる」みたいな話が面白かったです。
