Rails
Ruby

Railsのデザインパターンを使ってみた

RailsはMVC（Model-View-Controller）アーキテクチャに基づいたフレームワークですが、プロジェクトが大きくなるにつれて

#1. デザインパターンとは？

デザインパターン は、ソフトウェア開発におけるよくある問題を解決する「再利用可能な設計の型」です。

  • コードの可読性・保守性が向上
  • 同じ機能の実装でのバグを減らせる
  • チーム開発で共通の設計思想として活用できる

Railsでは以下のようなパターンが特に使われます。

#2. Railsでよく使われるデザインパターン

2-1. Service Object（サービスオブジェクト）

役割：モデルに書ききれないビジネスロジックをオブジェクトとして切り出す

例：ユーザー登録処理

# app/services/user_registration_service.rb
class UserRegistrationService
  def initialize(params)
    @params = params
  end

  def call
    user = User.new(@params)
    if user.save
      send_welcome_email(user)
      true
    else
      false
    end
  end

  private

  def send_welcome_email(user)
    UserMailer.welcome_email(user).deliver_later
  end
end

コントローラーでの呼び出し

def create
  if UserRegistrationService.new(user_params).call
    redirect_to root_path, notice: '登録完了'
  else
    render :new
  end
end
  • メリット：モデルやコントローラーが肥大化せず、処理の責務が明確になる

2-2. Presenter / Decorator（プレゼンター／デコレーター）

役割：ビューでの表示ロジックをモデルから分離する

例：ユーザー情報を整形

# app/decorators/user_decorator.rb
class UserDecorator < SimpleDelegator
  def display_name
    "#{first_name} #{last_name}".strip
  end
end

コントローラー

def show
  @user = UserDecorator.new(User.find(params[:id]))
end
  • ビューでは @user.display_name を使うだけで整形済みの名前が取得できる
  • メリット：ビューにロジックが散らばらず、モデルもシンプルに保てる

2-3. Observer（オブザーバー）

役割：モデルの変更に応じて処理を実行する

例：ユーザー登録後にメール送信

# app/models/user.rb
class User < ApplicationRecord
  after_create :send_welcome_email

  private

  def send_welcome_email
    UserMailer.welcome_email(self).deliver_later
  end
end
  • RailsではObserver専用のgemを使う場合もある
  • メリット：モデルの主要ロジックとは別に副作用処理を分離できる

2-4. Factory（ファクトリーパターン）

役割：複雑なオブジェクト生成をまとめる

例：FactoryBotでテストデータ生成

FactoryBot.define do
  factory :user do
    first_name { "Taro" }
    last_name { "Yamada" }
    email { "taro@example.com" }
  end
end
  • メリット：テストの可読性・再利用性が高まる

#3. Railsでデザインパターンを使うメリット

  1. 責務の分離
    • コントローラー・モデル・ビューが肥大化しにくい
  2. テストが書きやすい
    • Service Object や Presenter を個別にテスト可能
  3. 再利用性が高い
    • 同じ処理を複数箇所で使える
  4. チーム開発での理解が早い
    • 標準的なパターンで設計思想を共有できる

#4. まとめ

  • Railsでもデザインパターンを導入すると、コードが整理され保守性が向上する
  • Service Object, Presenter, Observer, Factory などが特に有効
  • 小規模アプリでは必要ない場合もあるが、中規模以上のプロジェクトではおすすめ

💡 実践のポイント

  • 最初からパターンにこだわりすぎず、必要に応じて導入する
  • 責務を明確に分けることを意識する

タグ一覧