狙い
本文は、前人の知見（@joker1007の記事、@k5trismegistusの記事）踏まえて、コールバッククラスのメリットとデメリットを述べて、さらに実践において、どのような状況で、それを使ったほうが良いのかについて論じてみる。
利弊
メリット
- モデルから、コールバックの処理（Railsガイドでは、「Active Recordオブジェクトが作成/保存/更新/削除/検証/データベースからの読み込み、などのイベント発生時に常に実行されるコード」と定義）といった責務を切り離れる。
- 異なるモデルでのコールバック処理の中から、汎用性の高い部分を抽出さして、カプセル化することで、メンテナンスしやすくなり、テストもしやすくなる。
デメリット
- いくつのモデルに使われた共通のコールバッククラスでの処理を変更したい時に、特定のモデルに対してその変更がいい、特定のモデルに対してその変更が悪いのようなケースが生じる可能性がある。
- 各モデルにコードバックを書くことと比べて、他のモデルにも影響が出るため、変更の際の確認・検証のコストが高くなる。
- 「他のモデルにも影響が出る」を見落としてしまった状況とつなぎやすくなり、ビジネスロジックの非意図的な変更やサービスの障害が起きる恐れがある。
適用条件
- コールバックの処理のコードの量が異常に多くて、かつ処理の複雑度が高くて、コードをメンテナンスしにくい場合
- メンテナンスをしやすくなることを目的として、コールバックの処理を切り離れる
- 切り離れたコールバックの処理をカプセル化する時に、他の人がそれを非意図的に使わないように、「明確な名前と境界」を付けることは重要である。
- 複数のモデルの中にある特に注力したい大事なコールバックの処理があり、それをドメイン知識として表現したい場合
- 上記の1と同じく、「明確な名前と境界」を付けることは重要である。（これはドメイン知識として成立する前提条件であるので、特に大事）
- 将来的に仕様の変更によって、その処理を修正する必要な時に、既存の「ドメイン知識」を修正したら十分なので、あるいは新たなドメイン知識が生まれることで、それらを再整理しないとけいないのかを考えることは重要である。