モデルとコールバッククラスの分離パターン

Railsで Model 本体と Model::Callbacks を別クラスに分ける設計パターンのまとめ。

2つのクラスの役割

class Model < ApplicationRecord

• app/models/model.rb にあるモデル本体
• ApplicationRecord（= ActiveRecord）を継承しているので、テーブルと1対1で対応する
• create! / find / update! などのDB操作の能力を持つ
• 定数・enum・ビジネスロジックのメソッドもここに置く

class Model::Callbacks

• app/models/concerns/model/callbacks.rb に置くただのRubyクラス
• 何も継承しない。テーブルとも対応しない
• 「コールバックで実行したい処理」だけを入れる入れ物

class Model::Callbacks
  class << self
    def after_commit(record)
      # コミット後に実行したい処理
    end
  end
end

:: の意味

:: は名前空間の区切り。Model::Callbacks は「Modelという名前空間の中のCallbacksクラス」という意味になる。

モデル本体とは別ファイル・別クラスだが、「Model専用の付属品ですよ」ということを名前で表している。specの配置（spec/models/concerns/model/callbacks_spec.rb）もこのディレクトリ構造をミラーする。

2つのクラスをつなぐ配線

モデル本体の1行がこの2つをつないでいる。

class Model < ApplicationRecord
  after_commit Callbacks # コミット後に Model::Callbacks.after_commit(レコード) を呼べ、という配線
end

after_commit にクラスを渡すと、Railsはそのクラスのコールバックと同名のクラスメソッド（ここでは after_commit）を、対象レコードを引数にして呼び出す。

なぜ分けるのか

1ファイルに全部書くこともできるが、意図的に分離することで次のメリットがある。

• モデル本体が肥大化しない（コールバックのロジックが増えてもモデルは太らない）
• 「保存時に何が起きるか」という副作用のロジックが1ファイルにまとまり、見つけやすい
• テストも callbacks_spec.rb として独立させられる

覚え方

• Model = データとDB操作
• Model::Callbacks = 保存イベントに反応する処理

この役割分担を規約として統一すれば、どのモデルでも同じ構造で読める。