Ruby de Railway Oriented Programming

dry-operationを使ったRubyでのRailway Oriented Programmingの紹介。

Kanazawa.rb meetup #156 at ビブリオバウムでの発表です。

1. Ruby de Railway Oriented Programming @wtnabe Kanazawa.rb meetup #156 at ビブリオバウム 2025-08-16 (Sat)
2. エラー処理ってむずい
3. 問題意識 1. 例外を処理の分岐や情報の伝播に使いたくない 捕捉しすぎは監視を欺くし、足りなければ異常終了という繊細さ 2. 適切にエラーの情報をユーザーに伝えたい
4. やりたくないこと 複雑な仕組みの学習 繊細なエラーハンドリング 繊細な分岐 ちまちましたエラー伝達のための詰め替え
5. やりたいこと ハッピーパスを書き連ねたい その他はいいがにしてほしい
6. Railway Oriented Programming
7. Railway Oriented Programming | F# for fun and profit 2014 年のアイディア（別に新しくない） 実態は Either を利用したエラーハンドリングのレシピ モナドに深入りするつもりはなく、これが唯一の方法でもない ドメインエラー（ドメインモデルのドメイン）で使うのがよい
8. F# の記述例 before bind nameNotBlank bind name50 bind emailNotBlank after bind nameNotBlank >> bind name50 >> bind emailNotBlank
10. dry-operation を使ったRuby の記述例 class UpdateCustomer < Dry::Operation def call step name_not_blank step name_50 step email_not_blank end end UpdateCustomer.new.call # => Dry::Monads::Result
12. dry-operation で実現していること
13. 基本的な使い方 Dry::Operation を継承したクラスを作る このcall メソッドの中に一連の処理を書く call メソッドは処理の最後の値をDry::Monads::Result で返す
14. 中身は何を書けばよいか この中の各step はDry::Monads::Result を受け取る 左辺は従来通り step は自動的にResult をunwrap して値を返す
15. 以上を踏まえてもう一度コード class SomeOperation < Dry::Operation def call(args) val1 = step <Resultを返すメソッド> val2 = step <Resultを返すメソッド> step <Resultを返すメソッド> end end SomeOperation.new.call(args) # => Dry::Monads::Result
17. dry-operation は何をしているか call の中身は別なmodule になる call はDry::Monads::Result を返す step はDry::Monads::Result を受け取ってunwrap して返す Result がFailure だったら例外を使って即脱出する 脱出時にはFailure を返す
18. 何が嬉しいのか ハッピーパスに集中できる 簡単なResult の基本だけ分かれば書ける 例外を使ってはいるが独自に書いていないので繊細さがない
19. Dry::Monads::Result とは dry-rb - dry-monads v1.6 - Result Success オブジェクトあるいはFailure オブジェクトのこと 値やメッセージの意味を明確にするためのオブジェクト（型） Rust とかあの辺りの流れ
20. モナドなんて知らんが？
21. dry-operation を使ううえでは ほとんど気にしなくていい
22. ROP に対する本人による5 年後の反論 Against Railway-Oriented Programming | F# for fun and profit なんでもかんでも Result にすべきでない Be careful when using Result for I/O errors などなど。まぁ最初から絶対の正解とは言ってない。
23. まとめ - dry-operation によるROP - Result こそ導入しているが関数型やモナドの知識はほぼ不要 現実的なスタートラインとして悪くなさそう
24. おまけ（本編） エラーってなんだ
25. Domain Modeling Made Functional における分類 Domain Errors ビジネスロジックであり、リッチなbool としてResult を使う Panics 例外でよい Infrastracture Errors ここが境界で、設計の腕の見せどころ Against Railway-Oriented Programming | F# for fun and profit
26. 意味分類 エラーの意味を知るユーザー 開発者 アクター（ユースケース的な意味） レジリエンス 回復可能 回復不能
27. 表現方法、実現方法 例外 エラー値（Go とかNode.js の組み込み関数のcallback とか） boolean をエラーの意味として返す Result
28. ざっくり特徴 例外はリッチな情報を持つが大域脱出が強すぎるし練度が必要 エラー値は書き味、読み味が煩雑 boolean は情報量が足りないし、通常の値と区別するのは利用側 Result は情報量は増えるがその分だけ手間は増える ↑ 関数型やその他のアプローチで短絡させるのがROP
29. 参考 Railway Oriented Programming | F# for fun and profit https://github.com/swlaschin/Railway-Oriented-Programming- Example Against Railway-Oriented Programming | F# for fun and profit Railway Oriented programming in Ruby: do notation vs dry- transaction | Igor Morozov dry-operation のススメとエラー情報をView まで持っていく方法の 模索 (2025-01-26) | あーありがち Result 型とRailway Oriented Programming をめぐる旅 (2025-02- 08) | あーありがち