ホーム › 入力値バリデーション › V-02
V-02: ビジネスルール検証
金額・納期・在庫数といった業務固有のルールを検証する方法を解説します。 V-01(数値・文字列・日付の形式チェック)との違いや、複数のルールを一括で評価してエラーを集約するパターンを学びましょう。
ビジネスルール検証とは
V-01 で学んだ「形式チェック」は、入力値が正しい形式かどうか(数値か・日付形式か・メールアドレス形式か)を検証します。 一方、ビジネスルール検証は「業務上の意味として正しいかどうか」を検証します。
形式チェックとビジネスルール検証の違い
| 種類 | チェック内容の例 | 対応するページ |
|---|---|---|
| 形式チェック | 「この文字列は整数か」「日付形式か」 | V-01 |
| ビジネスルール検証 | 「金額は0より大きいか」「納期は未来か」「在庫は足りるか」 | V-02(このページ) |
- 注文処理で金額・納期・在庫数をまとめて検証するとき
- 複数の条件を同時にチェックして、エラーをまとめてユーザーに返したいとき
- 業務ルールの追加・変更が頻繁に起きるシステムで、ルールを整理して管理したいとき
サンプルコード
Java 8 では ValidationResult をクラスで表現し、addError() でエラーを蓄積します。エラーが1件見つかっても処理を止めず、全フィールドをチェックしてから返すのがポイントです。
よくあるミス・注意点
バリデーションを呼び出し元に直接書きがち
注文処理の呼び出し元に if 文を直接並べて書くと、同じルールが複数の場所に散らばりメンテナンスが困難になります。 バリデーションロジックは専用のクラスやメソッドにまとめて、1か所だけ修正すれば全体に反映される設計にしましょう。
エラーメッセージが英語だけになりがち
エラーメッセージを「Invalid amount」のように英語だけで返すと、ユーザーや運用担当者が内容を理解しにくくなります。 「請求金額は0より大きい値を指定してください」のように、誰でも読める日本語メッセージを心がけましょう。 ただし、ログに残すシステムエラーは英語でも問題ありません。
最初のエラーが見つかったらすぐ return してしまいがち
1件目のエラーが見つかった時点で処理を中断すると、ユーザーは修正のたびに次のエラーを発見することになります。 全フィールドのチェックを最後まで実行してからまとめてエラーを返すことで、ユーザーが一度に全ての問題を把握できます。
テストする観点
- 金額の境界値:金額 = 0 のときエラーになること、金額 = 1 のときエラーにならないこと
- 納期の境界値:本日と同じ日付はエラー、明日以降はエラーにならないこと
- 在庫ぴったり:在庫数 = 注文数のときエラーにならないこと(在庫数 = 注文数 - 1 はエラー)
- 注文数 = 0 や負の数はエラーになること
- 全フィールドが不正な場合に複数エラーがまとめて返ること
- 全フィールドが正常な場合に isValid() が true を返すこと
- amount = null、deliveryDate = null でも NullPointerException が発生しないこと