副作用をどこに置くか問題：オブジェクト指向で整理する設計判断ツリー

https://fortee.jp/burikaigi-2026/proposal/25c3e254-082e-4dbc-9ded-22ad4d6eefe9

Transcript

1. 副作用をどこに置くか問題 オブジェクト指向で整理する設計判断ツリー Koya Masuda 株式会社マイベスト BuriKaigi 2026 2026-01-09 Powered by Rabbit 4.0.1
2. 自己紹介 増田紘也 (@koxya) 株式会社マイベスト エンジニア歴5年 Ruby歴5年 ( ) とクラフト が好き 初BuriKaigi 初富山 1/63
3. マイベスト 2/63
4. 最近のお仕事 商品情報の取得やランキング更新の自動化システムの改善 3/63
5. 今日話すこと システムに何か変更を加えるとき… 処理をどこに書くか 特に副作用を伴う場合にフォーカス なんとなくやってきた経験と知識をマッチングさせて整理 オブジェクト指向プログラミングが役立つ カプセル化 メッセージング ポリモーフィズム（多態） 抽象クラス 副作用をどこにどうやって書くべきか説明できるようになること を目指す 4/63
6. 副作用とは 主たる目的を達成する以外に、 外部から観察可能な環境に変化を引き起こすこと 例) 変数の更新 外部システムとの連携 ファイル書き込み メモリ領域の解放 ※ DBへの書き込みは更新が目的なことが多いので副作用として 扱わない 5/63
7. 副作用の扱いの大変なところ 処理順に意味が生まれる 実行されるコンテキストに依存する 状態に依存するためテストが困難になる ロールバック時に挙動が壊れる → 暗黙知を生み、結果の予測が難しく、変更によって壊れやすい 状態 6/63
8. こんな要件があったとき ユーザー登録時に… メアドは小文字にしたい パスワードはハッシュ化したい ログイン履歴を残す ウェルカムメールを送りたい 分析用にイベントログを記録したい どう実装する？ 7/63
9. 1つのメソッドにまとめる def register_user(params) # メアドを小文字に params[:email] = params[:email].downcase # パスワードをハッシュ化 params[:password] = generate_hash(params[:password]) user = User.create!(params) # DB書き込み LoginLogger.log(params) # ログイン履歴 UserMailer.welcome(user) # メール送信 AnalyticsEvent.track(user) # ログ記録 user end 8/63
10. 1つのメソッドの責務が多すぎる 変更に弱い 再利用性が低い 可読性が低い def register_user(params) params[:email] = params[:email].downcase # 正規化 params[:password] = generate_hash(params[:password]) # 正規化 user = User.create!(params) # 永続化 LoginLogger.log(params) # ログ UserMailer.welcome(user) # 通知 AnalyticsEvent.track(user) # ログ user end 9/63
11. 失敗時の挙動 ユーザーは作成済み ウェルカムメールが失敗 分析用のロギングは実行されない def register_user(params) params[:email] = params[:email].downcase # 成功 params[:password] = generate_hash(params[:password]) # 成功 user = User.create!(params) # 成功 LoginLogger.log(params) # 成功 UserMailer.welcome(user) # 失敗 AnalyticsEvent.track(user) # 実行されない user end 10/63
12. オブジェクトのライフサイクルにフックしてみる before_save → オブジェクトの保存直前に実行 after_commit → トランザクションのCOMMIT後 class User < ApplicationRecord before_save :normalize_email before_save :encrypt_password after_commit :send_welcome_mail after_commit :track_analytics_event def register_user(params) User.create!(params) end end 11/63
13. テスタビリティ スタブの嵐… ユーザー作成のテストをしたいだけなのに… class RegisterUserTest < ActiveSupport::TestCase test 'creates a user' do UserMailer.stub(:welcome, nil) do LoginLogger.stub(:log, nil) do AnalyticsEvent.stub(:track, nil) do # ネストが深くなる地獄 assert_difference 'User.count', 1 do register_user(email: 'test@example.com', password: 'password') end end end end end end 12/63
14. 処理を書く場所を2つの大枠で分類 オブジェクト指向（プログラミング）が役立つ オブジェクトの存在条件を守る 他の関心にメッセージを伝える ユースケースの一部か 独立した関心事か 13/63
15. ここか ら本題
16. 前提① Ruby on Railsを代表とするMVC（Model-View-Controller）のWeb アプリケーションのデザインパターンを用いて説明する 15/63
17. 前提② 呼称 他の呼び方 ここでの意味 オブジェクト インスタンス クラスnewしたもの フィールド メンバ変数 インスタンスごとに持 つ状態 モデル エンティティ Active Record パター ンのデータ構造をもち DB操作をするクラス 16/63
18. キースライド: 判断ツリー その副作用が失敗したらオブジェクトは不完全な状態になる？ │ ├─ YES → オブジェクトの存在条件 │ 例: パスワードのハッシュ化 │ → そのクラス(モデル)の中に書く │ └─ NO → 他の関心へのメッセージ │ その処理が失敗したら元の操作も失敗させたい？ │ ├─ YES → ユースケースの一部 │ 例: 決済、ポイント付与 │ → ユースケースを表すクラスにまとめる │ └─ NO → 独立した関心事 例: メール送信、Slack通知、ログ記録 → インターフェースを介して詳細を実装 17/63
19. キースライド: 判断ツリー その副作用が失敗したらオブジェクトは不完全な状態になる？ │ ├─ YES → オブジェクトの存在条件 ココ │ 例: パスワードのハッシュ化 │ → そのクラス(モデル)の中に書く │ └─ NO → 他の関心へのメッセージ │ その処理が失敗したら元の操作も失敗させたい？ │ ├─ YES → ユースケースの一部 │ 例: 決済、ポイント付与 │ → ユースケースを表すクラスにまとめる │ └─ NO → 独立した関心事 例: メール送信、Slack通知、ログ記録 → インターフェースを介して詳細を実装 18/63
20. オブジェクトの存在条件を守る 存在条件とは このオブジェクトが存在するなら、必ずこの状態である 例えば… ホテルの予約では以下を満たすということ チェックイン日 < チェックアウト日 予約者がいる 19/63
21. 存在条件かどうか見分けるコツ その副作用の結果以下を満たすなら「存在条件」 オブジェクトは不完全な状態になる？ Railsではコールバックやバリデーションの標準機能が用意されて いる class User < ApplicationRecord # オブジェクトの永続化時にバリデーションを行う validates :email, format: { with: URI::MailTo::EMAIL_REGEXP }, presence: true, uniqueness: { case_sensitive: false } end 20/63
22. どこにどうやって存在条件を書くか クラスの中のライフサイクルにフックさせる オブジェクト指向のデータと操作を一つにまとめる「カプセル 化」を行う カプセルが境界線を引く最小単位となる 存在条件を隠すことで、そのクラスの責務を明確にする 他のクラスからの信頼も得られる 21/63
23. 存在条件がクラスの中にないとどうなるか考える 口座(Account)クラスの残高(balance)は0以上でないとならない という存在条件があるときのコードを考えてみる 22/63
24. 存在条件がクラスの中にないと困ること うっかり外から更新できてしまう # account.balance # => 100 account.update!(balance: account.balance - 1_000) 23/63
25. 存在条件がライフサイクルにフックされていないと 似たメソッドが増殖する 口座（Account）の残高（balance）は0以上でないとならない という存在条件を確認して回る class Account def withdraw(amount) raise "残高不足です" if balance - amount < 0 # do something end def transfer_to(other_account, amount) raise "残高不足です" if balance - amount < 0 # do something end def monthly_fee!(fee: 500) raise "残高不足です" if balance - fee < 0 # do something end end 24/63
26. 存在条件のあるべき姿 # app/models/account.rb class Account < ApplicationRecord validates :balance, numericality: { greater_than_or_equal_to: 0 } def withdraw(amount) transaction do new_balance = balance - amount update!(balance: new_balance) # バリデーションで0未満を防ぐ end end end # 使う側はシンプル。実装の詳細は知らない。 account.withdraw(10_000) 25/63
27. 存在条件(Invariant)パートのまとめ 副作用が失敗したらオブジェクトは不完全な状態になるか？を 問う オブジェクトを定義するクラスにライフサイクルにフックして 処理を書く 26/63
28. 他の関心へメッセージ その副作用が失敗したらオブジェクトは不完全な状態になる？ │ ├─ YES → オブジェクトの存在条件 │ 例: パスワードのハッシュ化 │ → そのクラス(モデル)の中に書く │ └─ NO → 他の関心へのメッセージ ココ │ その処理が失敗したら元の操作も失敗させたい？ │ ├─ YES → ユースケースの一部 │ 例: 決済、ポイント付与 │ → ユースケースを表すクラスにまとめる │ └─ NO → 独立した関心事 例: メール送信、Slack通知、ログ記録 → インターフェースを介して詳細を実装 27/63
29. 他の関心へのメッセージの判断ポイント 他の関心へのメッセージ │ その処理が失敗したら元の操作も失敗させたい？ ココ │ ├─ YES → ユースケースの一部 │ 例: 決済、ポイント付与 │ → ユースケースを表すクラスにまとめる │ └─ NO → 独立した関心事 例: メール送信、Slack通知、ログ記録 → インターフェースを介して詳細を実装 28/63
30. 他の関心と運命をともにするとき 他の関心へのメッセージ │ その処理が失敗したら元の操作も失敗させたい？ ココ │ ├─ YES → ユースケースの一部 │ 例: 決済、ポイント付与 │ → ユースケースを表すクラスにまとめる │ └─ NO → 独立した関心事 例: メール送信、Slack通知、ログ記録 → インターフェースを介して詳細を実装 29/63
31. メッセージを伝える例 オブジェクトの状態を他の関心に伝える 例えば… 注文(Order)後にポイント(Point)を付与する どんなコードをイメージする？ 30/63
32. 存在条件と同じくライフサイクルにフック Orderの状態が注文完了になったらPointを作成する 注文(Order) → ポイント(Point) への依存が生まれる class Order < ApplicationRecord after_commit :grant_points, on: :update, if: :completed? private def grant_points point = Point.new(self.user, self.amount) point.save! end end 31/63
33. ライフサイクルにフックすると 暗黙知となる 他のチームや他のメンバーが知っておかないと事故る テスタビリティの低下 このクラスからテストデータの生成すると、セットでPointインスタンスも 作られる 増え続けるストーリー 管理画面からの手動注文作成ではポイントを付与しないで バッチ処理ではポイントを付与しないで 32/63
34. YAGNI（そんなもの、どうせ必要ない） 「プログラマは、それが実際に必要となるまで機能を追加 しない方が良い」 XPの共同創設者であるロン・ジェフリーズによって提唱された 以下自分の解釈 機能は良かれで追加してはならない 使われないことが多い 保守しないといけない 複雑な機能の抽象化はサボってはいけない 近い未来に見えていること 短期的なスピードだけ重視すると中・長期の早さを犠牲にしている 33/63
35. YAGNIの視点でもう一度見てみよう 注文が確定したら、注文したユーザーにポイントを付与する を実現するシンプルなコード…ではあるが class Order < ApplicationRecord after_commit :grant_points, on: :update, if: :completed? private def grant_points Point.new(self.user, self.amount) end end 34/63
36. コールバックはアンチパターン？ 35/63
37. コールバックはアンチパターン？ 36/63
38. 使いすぎると？ 一歩間違えるとコールバック地獄 class Order < ApplicationRecord after_commit :grant_points, on: :update, if: :completed? after_commit :create_delivery, on: :update, if: :completed? after_commit :create_invoice, on: :update, if: :completed? after_commit :record_purchase_history, on: :update, if: :completed? after_commit :update_stock, on: :update, if: :completed? private def grant_points Point.create!(user: user, amount: amount * 0.01) end def create_delivery Delivery.create!(order: self, address: shipping_address) end # 処理が続く... end 37/63
39. オブジェクトのライフサイクルにフックする場合 他の関心が少なく安定している 今後増える予定もない チーム、システムが小さく、コードの見通しが良い 他のエンジニアが見て驚かない 38/63
40. イベントに着目する データベースの制約（外部キーなど）はないが、ユースケースと して一貫性を保ちたい場合 今回だと、PointがなくてもOrderは成立するが、一緒に作成さ れていてほしい 「注文が完了した」というイベントに着目する → チェックアウト(Checkout) → このイベントをクラスにしてみる 39/63
41. Checkoutクラスを作成する 複数のオブジェクトを同一のTransactionで処理し、整合性を保 つ # app/models/checkout.rb class Checkout def initialize(order:, user:) @order = order @user = user end def execute ActiveRecord::Base.transaction do # 注文を完了状態にする @order.complete! # ポイントを付与する Point.create!(user: @user, amount: @order.amount * 0.01) end end end 40/63
42. イベントクラスのメリット・デメリット メリット トランザクションの範囲が明示的 Order と Point が同時に成功/失敗する テストしやすい コンストラクタから依存性注入できる デメリット うっかりで Order と Point 間の整合性を壊せる 個人的にはこれで十分かなと思っている 41/63
43. 運命をともにするパターンのまとめ 副作用が失敗したら元の操作も失敗させたい → ユースケースの 一部 データベースの制約はないが、ビジネス上の整合性を保ちたい 場合に有効 イベント（ユースケース）をクラスにする 例: Checkout, UserRegistration 同一トランザクションで複数のモデルを更新 モデル間の直接的な依存を避けられる ライフサイクルにフックする形でクラスの中に書いても良い ただし、拡張性やテスタビリティなどのトレードオフを理解しておくこと 42/63
44. 独立した関心事 他の関心へのメッセージ │ その処理が失敗したら元の操作も失敗させたい？ │ ├─ YES → ユースケースの一部 │ 例: 決済、ポイント付与 │ → ユースケースを表すクラスにまとめる │ └─ NO → 独立した関心事 ココ 例: メール送信、Slack通知、ログ記録 → インターフェースを介して詳細を実装 43/63
45. こんな要求が増えたとき 注文(Order)後にポイント(Point)を付与する + 注文完了メールを送りたい 44/63
46. 依存の向き 呼び出し側 → 呼び出される側 Checkout → Mailer class Checkout def initialize(order:, user:) @order = order @user = user end def execute ActiveRecord::Base.transaction do # 注文を完了状態にする @order.complete! # ポイントを付与する Point.create!(user: @user, amount: @order.amount * 0.01) end # メール送信 OrderMailer.perform_later(@user, @order) end end 45/63
47. 依存の数 もし要求がもっと増えたら… Checkout → Point, Mailer, Delivery, Invoice, Stock… 依存が多く、テストが大変、再利用しにくくて、変更しづらい class Checkout def execute ActiveRecord::Base.transaction do @order.complete! Point.create!(user: @user, amount: @order.amount * 0.01) end # メール送信 OrderMailer.perform_later(@user, @order) # Delivery.create # Invoice.create # Stock.decrease # ... end end 46/63
48. 依存性逆転の原則 - DIP ① 上位モジュールはいかなるものも下位モジュールから持 ち込んではならない。双方とも抽象（例としてインター フェース）に依存するべきである。 ② 抽象は詳細に依存してはならない。詳細（具象的な実装 内容）が抽象に依存するべきである。 依存の向き 上位モジュール(詳細) → 抽象 下位モジュール(詳細) → 抽象 https://ja.wikipedia.org/wiki/依存性逆転の原則 47/63
49. CheckoutとMailerをインターフェースに依存させる 依存性逆転の原則 (DIP) に従い、CheckoutとMailerの直接的 な依存をなくす インターフェースを用いて依存の向きを逆転させる 使う側もインターフェースを信頼して使う 具体的な処理（メール送信）にはインターフェースだけを利用する 48/63
50. インターフェースの作成 Checkoutはインターフェースを知っているだけにする # ========== 抽象（インターフェース） ========== module CheckoutSubscriber def on_checkout(user, order) # 未実装時に例外とする raise NotImplementedError, "#{self.class}で#{__method__}が実装されていません" end end 49/63
51. Checkoutクラスから抽象に依存する subscriberはon_checkoutメソッドを持っているものとする = ダックタイピング (多態性を表現する技術) class Checkout def initialize(order:, user:) @order = order @user = user @subscribers = [] # <- 追加 end def execute ActiveRecord::Base.transaction do @order.complete! Point.create!(user: @user, amount: @order.amount * 0.01) end + subscribers.each { |subscriber| subscriber.on_checkout(@user, @order) } - OrderMailer.perform_later(@user, @order) end end 50/63
52. メール送信の詳細を作成 インターフェースをmix-inする 抽象メソッドをオーバーライド class OrderMailer include CheckoutSubscriber def on_checkout(user, order) perform_later(user, order) end def perform # メール送信処理 end end 51/63
53. 使うときは checkout = Checkout.new(..) checkout.subscribers = [ OrderMailer.new # インターフェースの約束を守れば拡張できる # DeliveryCreator.new # InvoiceCreator.new # StockUpdater.new # ... ] checkout.execute 52/63
54. 実装のコツ 上から順に実装すると、詳細を知らずに抽象に依存するというこ とをクラスの視点に立って理解できる 抽象クラスの作成 シグネチャだけ決める 呼び出し側を抽象に依存させる 詳細の実装がどうなっているかは知らない 詳細の実装 抽象に依存して、詳細だけに集中する 53/63
55. 最終どうなったか 54/63
56. Transaction に含めてはいけないケース ロールバックできないもの class Order < ApplicationRecord def checkout(payment) transaction do complete! # 1. 注文ステータス更新 PaymentApi.charge(payment) # 2. 課金実行（HTTP通信 → 成功） Inventory.decrease(items) # 3. 在庫減算 → 在庫不足で例外発生！ OrderMailerJob.perform_later(self) # 4. 実行されない end # トランザクションがロールバック # - complete! → まだ commit していないから戻る # - PaymentApi.charge → 戻らない（外部APIは戻せない） # # 結果: 注文はキャンセル状態、でも顧客のカードからは引き落とし済み end end 55/63
57. 抽象に依存させる class Order < ApplicationRecord def checkout(payment) # 1. 同じトランザクションで成功/失敗すべき処理 transaction do complete! Inventory.decrease(items) end # 2. 同期処理が必要: 決済（同期、レスポンスに必要） # リトライ機構は PaymentApiに任せる result = PaymentApi.charge(payment) Payment.create!(order: self, status: result.status) # 3. 他の関心事: メール（非同期、レスポンスに不要） OrderMailJob.perform_later(self) end end 56/63
58. 外部APIのレスポンスがデータ整合性に必要な場合は 注意 外部サービスからのレスポンスをもって、一連の処理を完了とする場 合 同期的に処理をしないと行けないケースはある 例）外部決済サービスを使っているとき 57/63
59. 他の関心へメッセージ ~ 独立した関心事 のまとめ 関心が多い場合、詳細は抽象に依存するように抽象クラスを作 成する 依存の向きを逆転させる ロジック（メール送信）はインターフェースに依存させる メッセージを送る側も抽象に依存するようにする 58/63
60. まとめ どんな副作用を伴うか考える オブジェクトが不完全な状態になるか？ その処理が失敗したら元の操作も失敗させたい？ ユースケース？独立した関心事？ 基本的にライフサイクルにフックするのはオブジェクトの存在 条件を満たしたいときだけ 別々のオブジェクトをの整合性を保ちたいときはイベントに着 目しよう イベントクラスが作れると嬉しい 他の関心へのメッセージは依存の向きを意識しよう 抽象に依存することで将来の変更に強くなる 59/63
61. 参考書籍 https://bookplus.nikkei.com/atcl/catalog/21/S00180/ https://gihyo.jp/magazine/wdpress/archive/2023/vol132 https://amzn.asia/d/i6uMp0V https://amzn.asia/d/5MIDQD9 https://www.poodr.com/ 60/63
62. 参考記事 https://ryym.tokyo/posts/my-rails-practice1/ https://speakerdeck.com/igaiga/kaigionrails2024/ https://qiita.com/joker1007/items/25de535cd8bb2857a685 https://little-hands.hatenablog.com/entry/2021/03/08/aggregation 61/63
63. さいごに 一人じゃどうしようもない チームや組織で話し合って目線を揃えないと改善されない 何かトレードオフの判断をするときは意思決定の記録をしよう 62/63
64. おわり