業務アプリケーションでリアクティブ化するところ、しないところ

2026/5/30
https://ccc2026spring.java-users.jp/
JJUG CCC 2026 Spring

Transcript

1. 業務アプリケーションで リアクティブ化するところ、しないところ 2026/5/30 Lambig
2. 自己紹介 Lambig ランビグ (株式会社ニーリー テックリード) https://github.com/lambig We’re hiring! この辺の領域やってます 釧路移住民です
3. 質問1 • リアクティブなサーバーサイドアプリケーションを ◦ 開発・運用していますか？ ◦ 検討していますか？
4. 質問2 • リアクティブ業務アプリ検討・開発で ◦ Clean系実装を想定・実装していますか？ ▪ リアクティブ・ブロッキングの境界線を引いていますか？ • リアクティブ実装 • ブロッキング実装
5. 業務アプリケーションで リアクティブ化するところ、しないところ
6. はじめに • 実例、実際のお悩みベースです ◦ 正解をお出しできているかは不明です ◦ これからお話しする方法で今はイケています ◦ イベント駆動化はしていません ▪ する可能性は想定している、位です • 今回しないお話 ◦ リアクティブアプリケーションそのもののお話 ◦ Clean系そのもののお話
7. リアクティブ業務アプリのサクっと答えが出てこない話 • どこをリアクティブに書く？ ◦ 全部？ ◦ 特定レイヤ(インフラとか)？
8. リアクティブ業務アプリのサクっと答えが出てこない話 • 全部リアクティブ ◦ Pros ▪ 発想はシンプル ▪ I/O境界からユースケースまで流れが一貫する ▪ ブロッキング混入を発見しやすい
9. リアクティブ業務アプリのサクっと答えが出てこない話 • 全部リアクティブ ◦ Pros ▪ 発想はシンプル ▪ I/O境界からユースケースまで流れが一貫する ▪ ブロッキング混入を発見しやすい ◦ Cons ▪ 記述量がやたら増える • 業務知識の読み取りが大変 ▪ メンバー全員がリアクティブ読み書き必須に
10. リアクティブ業務アプリのサクっと答えが出てこない話 • 一部リアクティブ ◦ Pros ▪ うまく行けば技術と業務をある程度分離できるかも • 新規参画メンバーに少し優しい作り • LLM(とレビュアー)フレンドリー
11. リアクティブ業務アプリのサクっと答えが出てこない話 • 一部リアクティブ ◦ Pros ▪ うまく行けば技術と業務をある程度分離できるかも • 新規参画メンバーに少し優しい作り • LLM(とレビュアー)フレンドリー ◦ Cons ▪ 線引きどうしましょう ▪ 判断するならミスもあるかも
12. リアクティブ業務アプリのサクっと答えが出てこない話 • 一部リアクティブでやってみることにしました ◦ とりあえず業務判断を字面で解りやすくしたい ◦ 分割基準の提案: ▪ 業務"判断"とそれ以外を分ける
13. 業務処理のうち、業務判断を切り出してみる • 業務処理 ◦ 受け取った情報、あるいは処理開始時のコンテキストに対して ▪ 足りない情報を外部から補足する ▪ 既にある情報から何らかの値や結論を導き出す ▪ 業務を遂行する • 何かを記録する • 外部に値や結論を発信・返答する
14. 業務処理のうち、業務判断を切り出してみる • 業務処理 ◦ 受け取った情報、あるいは処理開始時のコンテキストに対して ▪ 足りない情報を外部から補足する ▪ 既にある情報から何らかの値や結論を導き出す ▪ 業務を遂行する • 何かを記録する • 外部に値や結論を発信・返答する
15. 業務処理のうち、業務判断を切り出してみる • 業務処理 ◦ 受け取った情報、あるいは処理開始時のコンテキストに対して ▪ 足りない情報を外部から補足する ▪ 既にある情報から何らかの値や結論を導き出す • 業務知識が一番乗ってくるのがココと仮説 ◦ ここが同期で書かれていれば読みやすそう ▪ 業務を遂行する • 何かを記録する • 外部に値や結論を発信・返答する
16. 業務判断をブロッキング化する • 業務判断ではブロッキング ◦ 業務モデルのメソッド • 業務処理一般はリアクティブ ◦ アプリケーションサービス ◦ リポジトリのメソッド
17. 業務判断をブロッキング化する • ドメインサービスは？
18. 業務判断をブロッキング化する • ドメインサービスは？ ◦ 松: 判断か一連の処理かでブロッキング・リアクティブの2種類 ▪ 筋としては正当 ◦ 竹: 妥協して全部非同期 ▪ 設計上の考慮点を減らす
19. 業務判断をブロッキング化する • ドメインサービスは？ ◦ 松: 判断か一連の処理かでブロッキング・リアクティブの2種類 ▪ 筋としては正当 ◦ 竹: 妥協して全部非同期 ▪ 設計上の考慮点を減らす 採用したのはこちら
20. 業務判断をブロッキング化する • ドメインサービスは？ ◦ 松: 判断か一連の処理かでブロッキング・リアクティブの2種類 ▪ 筋としては正当 ▪ モデルを跨いだ処理は後から外部依存が発生しがち • I/Fが変わると変更時がちょっと大変かもと思った ◦ 竹: 妥協して全部非同期 ▪ 設計上の考慮点を減らす • LLMベース実装を考慮に入れると無視できない
21. 業務判断をブロッキング化する • ドメインサービスは？ Hindsight ◦ 判断・処理で分けた方が良かったかも ▪ 構造やオブジェクトの役割が明確化する ▪ LLMベース実装の対応は実装ルールで縛れる気がする
22. ところで: 正常系以外のハンドリング • リアクティブフレームワークの基本機能 ◦ 失敗系 ▪ エラー検出・通知 ▪ リトライ ▪ リカバリ ◦ 例外を失敗系に流してくれる機能 ◦ いわゆる業務エラー(準正常系)をこれに乗せる？
23. ところで: 正常系以外のハンドリング • リアクティブフレームワークの基本機能 ◦ 失敗系 ▪ エラー検出・通知 ▪ リトライ ▪ リカバリ ◦ 例外を失敗系に流してくれる機能 ◦ いわゆる業務エラー(準正常系)をこれに乗せる？ ▪ 乗せませんでした
24. ところで: 正常系以外のハンドリング • 準正常系の扱い ◦ 処理中断ではなく正当な結果の一部として扱いたい ◦ 実例が基盤寄りシステムなので準正常系は結構ありそう ▪ fillInStackTraceあんまり呼びたくないなぁの想い
25. ところで: 正常系以外のハンドリング • 準正常系の扱い ◦ 処理中断ではなく正当な結果の一部として扱いたい ◦ 実例が基盤寄りシステムなので準正常系は結構ありそう ▪ fillInStackTraceあんまり呼びたくないなぁの想い • その上あまり役に立たないし ▪ こちらはそこまで気にしなくてよいかも ◦ Result型定義して対応しました ▪ 処理の戻りはUni<Result<E>>とかSingle<Result<E>>
26. ところで: 正常系以外のハンドリング • 準正常系 ◦ Result.Failureで扱う • 異常系 ◦ 失敗系パイプライン(例外)で扱う
27. ところで: 正常系以外のハンドリング • 準正常系 ◦ Result.Failureで扱う • 異常系 ◦ 失敗系パイプライン(例外)で扱う 体感楽かなとは思います
28. 閑話休題
29. ざっくり実装例 • イメージを掴んでもらえれば
30. ざっくり実装例 • 処理側 ◦ 会員を退会させてみる ▪ 退会可能(有効)？ ▪ 未払い？ • Quarkus(Mutiny) 実プロダクトでは 状態遷移のインスタンスメソッド実装は禁止 (遷移先クラスのstatic factoryに定義する)なんですが 今回は例なので……
31. ざっくり実装例 • 処理側 ◦ 会員を退会させてみる ▪ 退会可能(有効)？ ▪ 未払い？ • Vert.x(RxJava)
32. ざっくり実装例 • 処理側 ◦ 会員を退会させてみる ▪ 退会可能(有効)？ ▪ 未払い？ • Spring WebFlux(Project Reactor)
33. というわけで • どのF/Wも似たような感じで実現可能 ◦ リアクティブ実装の処理から判断を呼ぶ流れ ◦ 判断はブロッキング処理で実装
34. ちなみに実際のプロダクトはこんな感じでした • 2026/04 リリース ◦ 安定稼働中✌ • Kotlin 2.3.10 (Java25) • Quarkus(Mutiny) • 全エントリポイントリアクティブ ◦ 要請というより判断削減 • プロダクト内のメンバーへの実装依頼 ◦ レビューがめちゃくちゃ楽でした • 現在チーム外への実装依頼中 ◦ ここもうまく乗っかってもらえると期待
35. 余談 • ゼロ・オーガニックコード • detektルール実装(現在27) ◦ 判断ミスを減らす • 観点別LLM並列レビュー ◦ 先にレビュー観点を作る ◦ 型化したところからdetektに逃がした
36. まとめ • リアクティブCleanは実現可能(少なくとも今はできている) • 非同期処理をスコープ管理しましょう ◦ 今回の例では業務判断は同期、それ以外は非同期 ◦ そうでなくても最初に線を引きましょう
37. ありがとうございました