はじめに

個人開発でRailsアプリを作成する中で、コントローラーが肥大化していくことに悩んでいました。1つのアクションにロジックが詰め込まれ、「動くけど読みにくい」状態になっていました。この記事では、Fat Controllerをどう設計改善したか、UseCaseクラス導入のプロセスと学びをまとめます。

Fat Controllerとは

処理をコントローラ内で引き受けすぎてしまっている
コントローラ内のコードの量も、ロジックの量も増えている
コントローラ内にあらゆる実装を書き込んでいる

必要以上にコントローラ内のコードがある状態をFatControllerと言います。

Fat Controllerはなぜよくないのか

コード量が増えすぎて、可読性が下がる
ロジックが埋もれて、再利用しづらい
テストがしにくく、保守性が悪化

Fat Controllerについては下記の記事がわかりやすく書いてありました。

解消方法

ここで必要となってくるのが単一責任の原則とDRY原則という考え方です。

単一責任の原則（SRP: Single Responsibility Principle）

定義

「ソフトウェアの各コンポーネント（クラス、モジュールなど）は、それぞれ1つの責任のみを持つべきだという原則」
つまり、1つの役割・目的だけを持つようにすることで、責務が明確になり、他のコードへの影響が最小限になる。

DRY原則（Don't Repeat Yourself）

定義

「同じロジック・知識を複数箇所に書かないこと」
同じコードを何度も書くことを避け、1か所にまとめて記述することで、保守性や可読性を向上させる。

実際のコード

Before

#app/controllers/users_controller.rb
class UsersController < ApplicationController
  def update_password
    @user = current_user

    if @user.authenticate(params[:user][:current_password])
      if @user.update(params.require(:user).permit(:password, :password_confirmation))
        flash[:notice] = "パスワードを変更しました"
        redirect_to edit_password_user_path
      else
        flash.now[:alert] = "パスワードの更新に失敗しました"
        render :edit_password, status: :unprocessable_entity
      end
    else
      @user.errors.add(:current_password, "が正しくありません")
      flash.now[:alert] = "変更に失敗しました"
      render :edit_password, status: :unprocessable_entity
    end
  end
end

この書き方の問題点

認証・更新、エラー処理、画面遷移が1アクションに纏められている
コントローラのコード量が増え、可読性が下がる
テストもしづらく、変更時の影響範囲が広い

After

UseCaseクラスによる責務分散

#app/controllers/users_controller.rb
def update_password
  service = UpdatePassword.new(
    current_user,
    current_password: params[:user][:current_password],
    new_params: password_params
  )

  if service.call
    flash[:notice] = "パスワードを変更しました"
    redirect_to edit_password_user_path
  else
    flash.now[:alert] = "変更に失敗しました"
    render :edit_password, status: :unprocessable_entity
  end
end

private

def password_params
  params.require(:user).permit(:password, :password_confirmation)
end

#app/usecases/update_password.rb
class UpdatePassword
  def initialize(user, current_password:, new_params:)
    @user = user
    @current_password = current_password
    @new_params = new_params
  end

  def call
    if @user.authenticate(@current_password)
      @user.update(@new_params)
    else
      @user.errors.add(:current_password, "が正しくありません")
      false
    end
  end
end

設計改善ポイント

単一責任の原則（SRP）を守れる

以前のFat Controllerでは、1つのメソッドが「認証」「更新」「フラッシュメッセージの出力」「画面遷移」など、複数の責務を抱えていました。

UseCaseを導入したことで、認証・更新処理はUseCaseに委譲
フラッシュや画面遷移はControllerに限定と、役割を明確に分けられ、どこを変更すればよいかもはっきりしました。

Fat Controller を避けられる

責務の分離により、コントローラーの処理が短く、読みやすくなりました。update_password の中身が「処理を呼び出す」だけになったことで、流れが明確に把握でき、保守性が格段に上がりました。

DRY原則の実現

同じような処理（バリデーションやパラメータ処理）が複数箇所に分散していると、修正漏れやバグの温床になります。
UseCase導入によって、重複しやすいロジック（認証や更新）を1か所にまとめられたことで、変更時の影響範囲を最小限にできました。

テストがしやすくなる

UseCaseクラスはコントローラーから切り離されているため、RSpecでの単体テストが可能になりました。
たとえば、認証失敗や更新失敗のケースを明示的にテストできます。

得られた学び

今回の改善を通して、設計や保守性に対する考え方が大きく変わりました。

まず、Fat Controllerがなぜ問題なのかを実感しました。認証や更新、フラッシュメッセージの制御といった処理を1つのアクションに詰め込むことで、コードの見通しが悪くなり、バグの温床になりやすいことを痛感しました。

そこでUseCaseクラスを導入することで、パスワード変更という単一の責任を切り出し、コントローラーでは処理の流れだけに集中できるようになりました。結果として、単一責任の原則（SRP）を意識した保守しやすい設計へと改善されました。

また、重複しやすいロジックをUseCaseに集約したことで、DRY原則（Don't Repeat Yourself）も実践できました。1か所を修正すれば全体が改善される設計になり、将来的な仕様変更にも柔軟に対応できます。

さらに、UseCaseは外部依存が少なく、RSpecでの単体テストが非常にしやすくなりました。認証失敗やバリデーション失敗といったシナリオを分離して検証できることで、品質保証にもつながりました。

コードの可読性、保守性、再利用性、テストのしやすさという点で、UseCaseパターンは非常に有効であると体感しました。

「とりあえず動く」から一歩進み、コードの役割を明確に分離する設計を目指しました。UseCaseクラスによってコードの見通しが良くなり、保守や機能追加のしやすさにもつながっています。