4分間でわかった気になるRailway Oriented Programming

Transcript

1. 4分間でわかった気になる Railway Oriented Programming 2025年11月23日
2. シマ ユウキ 富山県高岡市出身 大学時代は石川県金沢市に住ん でいました TypeScript好き 2 自己紹介
3. 今日話すこと Railway Oriented Programmingのエッセンス 今日話さないこと TypeScriptでもResultを使おうという話はしません！！ 会社紹介 ミッションは「スタートアップエコシステムをブーストし、日本からGoogle級のスタートアップを生み出す」 フロントエンドはTypeScript、バックエンドKotlin/Javaです 3 4分間でわかった気になるRailway Oriented Programming
4. Railway Oriented Programming（ROP） 「関数型ドメインモデリング」の著者Scottさんが2014年に発表 関数型プログラミングでのエラーハンドリングを初心者にもわかりやすく説 明した 関数を「成功」と「失敗」の2つの分岐がある鉄道の比喩で直感的に示した 日本語版では「鉄道指向プログラミング」と訳されています ※スライド中では本のことをDMMF本、Railway Oriented Programmingを ROPと略します 関数型ドメインモデリング Scott Wlaschin 著
 猪股 健太郎 訳 https://asciidwango.jp/post/754242099814268928/ %E9%96%A2%E6%95%B0%E5%9E%8B%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3% E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0 4 4分間でわかった気になるRailway Oriented Programming
5. 3つのエラー分類 パニック 処理不可能なシステムエラー（メモリ不足、ゼロ除算など） インフラストラクチャエラー アーキテクチャの一部として予想されるエラーだが、ビジネスプロセス の一部ではないもの（ネットワークタイムアウト、認証エラーなど） ドメインエラー ビジネスプロセスの一部として予想されるエラー（ECなら在庫が足りな い、無効な製品コードなど） これをROPで扱うと良いとされている 5 4分間でわかった気になるRailway Oriented Programming
6. Railway Oriented ProgrammingのRailway 成功を緑のレール、失敗を赤のレールで表現 緑のレールを走っている間（成功）は、次の処理を 実行する 赤のレールを走ることになったら（失敗したら）次 の処理はバイパスする 戻り値は必ず同じ型（Result） 連ねたものをワークフローと呼ぶ 筆者のスライドから引用 https://github.com/swlaschin/RailwayOrientedProgramming 6 4分間でわかった気になるRailway Oriented Programming
7. Railway Oriented Programmingを支えるResult 関数がどんな返り値が存在するかを「型」で示す Result<Ok, Err>だとすると OKの間はずっと緑のレール Errorになったら赤のレール 右の場合10個より買おうとするとエラー 関数型でよくあるパターン 言語によって名前が違ったりする TypeScriptにはない 7 4分間でわかった気になるRailway Oriented Programming 筆者のスライドから引用 https://github.com/swlaschin/RailwayOrientedProgramming
8. 線路を繋ぐときに出てくるのが「bind/flatMap」 処理が連続した時に繋げるのがbind/flatMap 緑のレールを走っている間（成功）は、次の処理を 実行する 赤のレールを走ることになったら（失敗したら）次 の処理はバイパスする 8 4分間でわかった気になるRailway Oriented Programming 筆者のスライドから引用 https://github.com/swlaschin/RailwayOrientedProgramming
9. 結果が型に現れる 9 4分間でわかった気になるRailway Oriented Programming バリデーションと在庫チェックを行なった結果起き うるのは３パターンと型が示している OK １０個以上買おうとしてNG 在庫不足でNG
10. エラーのパターンがふえたとき 10 4分間でわかった気になるRailway Oriented Programming ハンドリングの不足を型レベルで怒ってくれる バリデーションと在庫チェックを行なった結果起き うるのは３パターンから４パターンに OK 在庫不足でNG １０個以上買おうとしてNG ０個買おうとしてNG←NEW
11. ROPのメリット：それぞれの処理の失敗を抽象化して扱うことができる 11 4分間でわかった気になるRailway Oriented Programming バリデーションに失敗したとしても在庫不足でも ワークフローはかわらない 失敗したら同様に後続処理がスキップされる ということは バリデーションのパターンが増えてもワークフロー は安定 Errorの種類が増えても同じようにレールに乗る だけ 他の関数は触らなくてOK 関数の独立度が高いのでテストも書きやすい 増えたエラー自体は型に現れる
12. ROPのメリット：それぞれの処理の失敗を抽象化して扱うことができる 12 4分間でわかった気になるRailway Oriented Programming バリデーションに失敗したとしても残高不足でも ワークフローはかわらない 失敗したら同様に後続処理がスキップされる ということは バリデーションのパターンが増えてもワークフロー は安定 Errorの種類が増えても同じようにレールに乗る だけ 他の関数は触らなくてOK 関数の独立度が高いのでテストも書きやすい 増えたエラー自体は型に現れる ROPのエッセンス エラーハンドリングの扱いに着目した手法 失敗を型（Result<Ok, Error>）で表現することで、成功か失敗かを判別可能にする flatMapが型を見て、成功なら次の処理を実行、失敗ならスキップして伝播する if文や例外処理を書かずに、複数の処理を安全に連鎖できる
13. いつでも使うべき？TypeScriptとの相性は？ ResultはTypeScriptの標準にはない仕組み パターンマッチングやパイプラインがない（型の絞り込みなどはできる） ROPの利点である「例外処理を呼び出し元に強制できる」ほどではない 自分で実装、サードパーティライブラリなどの選択肢はあるが、標準から離れる覚悟は必要 有効な箇所は？ 起きうるエラーを分類し、ドメインエラーかどうかを考えるのには有効 また、それを値として扱うと便利か、I/Oを分離できるかなどがファクターになりえる 筆者のScottさんも軽率には使うなと書いている Against Railway-Oriented Programming 13 4分間でわかった気になるRailway Oriented Programming
14. ROPを知ることで得られる栄養がある。それは、呼び出し側への意図の表明 起きうる結果を型で表すという発想は、「呼び出し側への意図の表明」という利点がある 「あり得る状態だけを型定義するべき」 この処理（関数）で起きうることが型によって文書化できているとも言える。AIにも優しい。 表明ではなく強制を求めるなら他の言語かも（TSでもできる） ROPは「起きた結果の処理の抽象化」という点でとても噛み合わせがいい。文字通り関数を”合成”することでドメイ ンを表現できる プロダクトにおける様々な例外、中でもドメインエラーを扱う一つの手段としてROPがある エラー分類などは普遍的な内容（言語標準にResultがあるかないかではないよ） 14 4分間でわかった気になるRailway Oriented Programming
15. ご清聴ありがとうございました Nstockブースに来てね！キーホルダーもあるよ！ ResultをTypeScriptのプロジェクトで使っているよ・使うのやめたよの話があればぜひ聞かせてください！ 15 4分間でわかった気になるRailway Oriented Programming