エンティティでのバリデートについて

Question

ビジネスロジックのバリデートについて

Laravelでエンティティとバリューオブジェクトとサービスとリポジトリを利用したパターンでWEBアプリケーションを作成しています。

果物はりんご、みかん、ぶどう、しか存在しないというビジネスロジックがあり、
果物がそのいずれかであることを担保する場合。

果物のバリューオブジェクトを作成し、
そのコンストラクタでバリデートをおこなうべきだと思ったのですが、
同僚にフォームリクエストで行うべきだと指摘されました。

フォームリクエストは入力値のチェックだけで、
あくまで、果物が「りんご、みかん、ぶどう」であるというビジネスロジックのバリデートは
バリューオブジェクトで行うべきだと思うのですが、
この考えは間違えているのでしょうか？

【追記】
このバリデートの前提として、果物の値のリクエストがあり、それに対してのバリデートとなるのですが、
同僚の指摘の意図は、それはリクエスト内容なので、フォームリクエストで行うべきといっていました。

私は、それに対してフォームリクエストでビジネスロジックのバリデートを行う場合、
果物のバリューオブジェクトを他の箇所でも再利用する場合、必ずフォームリクエストでバリデートすることを
覚えておかなければいけない為、ミスが起こりやすい設計ではないかと指摘しました。
また、フォームリクエストがビジネスロジックを持つことは、フォームリクエストの責務を越えていると思うと伝えました。
それに対して、同僚はリクエストなので、ビジネスロジックであっても、フォームリクエストがバリデートすることは、
フォームリクエストの責務を越えていないという考えでした。

私はバリューオブジェクトの値の正当性はバリューオブジェクト自身が担保するべきという考えで、
同僚はバリューオブジェクトの値の正当性は、その前の段階で値の正当性を担保し、
それをバリューオブジェクトに渡すべきという考えでした。

Comments

[m.ts10806]

興味による確認なのでこちらに書きますが、その同僚の指摘をどのような意図があったか確認（もしくは議論）されましたか？気になるので、そのあたり分かる範囲で結構ですので質問本文に追記いただければと思います。

[退会済みユーザー]

質問意図が分からないのでソースコードを追記して欲しいです。

Answer 1

だいぶ前の質問ですが気になったので。

個人的には両方書くことが多いです。要約すると、

• ビジネスロジックでのバリデーションは必須。
• 入力バリデーションの時点で弾くかどうかはAPIの要件に依る
• セキュリティの観点から見ると入力バリデーションを厳しくするメリットはある

という意見です。以下詳細。

● ビジネスロジック
ビジネスロジックでの担保は必須だと思います。
ドメインのエンティティやバリューオブジェクトは常にHTTP層からアクセスされるわけではありません。（Laravelを使ったプロジェクトでもコンソールコマンドから呼ばれるかもしれませんし）
この部分をUI層であるHTTP層に頼らず、ドメインの中で不正な操作が起きないようにするのはとても良い習慣です。

個人的には果物のVOをEnumのようなクラスにして使うことが多いですね。

参考: https://qiita.com/Hiraku/items/71e385b56dcaa37629fe

class FruitType extends Enum
{
	public const RINGO = "りんご";
	public const MIKAN = "みかん";
	public const BUDOU = "ぶどう";
	
	// abstractなEnumクラスでコンストラクタで定数にした値が入るとInvalidArgumentExceptionなどを投げるようにしてある
}

● HTTPリクエストのバリデーション（APIの仕様の観点から）
HTTPリクエストのバリデーションでエラーとして弾くべきかどうかは、究極的にはAPIに求められる仕様によると思います。
不正な果物の種類がHTTPリクエストのパラメータとして入ってきた時のAPIの挙動について考えます。

レスポンスをステータスコード422で返して、"果物の種類の値はりんご、みかん、ぶどうのいずれかで指定してください"というエラーメッセージを出す

というような要求があるならば、HTTP層でもフォームリクエストでバリデーションを行うべきでしょう。

不正な値については単に500エラーで落ちても良いというのであれば、ビジネスロジックでの担保だけで良いかもしれません。

● FormRequestを使う場合の小ネタ
ビジネスロジックでもFormRequestでもバリデーションを行う場合、なるべくコードはDRYにしたいので、先ほどのEnumに全ての値を取得する静的メソッドを設けたりします。

// Laravel>=5.6の場合、FormRequestでRuleクラスを使うとスッキリ書ける

use Illuminate\Validation\Rules\In;

class FruitFormRequest extends FormRequest
{
    public function rules()
    {
    	 $allFruitTypes = FruitType::allValues();
    	 // ['りんご', 'みかん', 'ぶどう']

         return [
             'fruit_type' => ['required', new In($allFruitTypes)],
         ];	
     }
}

●HTTPリクエストのバリデーション（セキュリティの観点から）
もう一点、詳細な入力バリデーションを後押しする要素としては、セキュリティがあります。

多層防御という考え方があります。
複数のモジュールでデータを検証すると冗長にはなりますが、その冗長性は安全性とのトレードオフです。検証の一部の処理が間違っていたり忘れられていたとしても、他の防衛ラインが機能することで防げる場合もあるからです。

入力データの検証はLaravelを使ったWebアプリケーションの最初の防壁として大事な役目を果たします。
この時点で"正しく動作し得ない"データを削るのは良い考えです。

複雑ではないAPIであっても、開発に複数人が関わるのであれば厳しめの入力バリデーションをお勧めします。

Comments

[unamu]

丁寧なご説明ありがとうございます。
APIの求める仕様に対応するのにフォームリクエストを利用するというのが、
フォームリクエストの使い所というのがとても納得できました。

APIの要件でエラーメッセージが何でも良い場合は、
VOから「果物の設定の値が不正です」のような、例外を投げて、それをコントローラーでキャッチして
ユーザーに表示しても良いものなのでしょうか？
それともVOからの例外はキャッチせずにエラーで落とすべきなのでしょうか？

[n_1215]

> VOから「果物の設定の値が不正です」のような、例外を投げて、それをコントローラーでキャッチして
ユーザーに表示しても良いものなのでしょうか？
そういう設計も可能ですね。

ユーザには見せたくないエラーメッセージもあるのが一般的だと思いますので、例外を投げるにしても複数の種類を使い分ける必要は最低限出てくるのではないかと思います。
例えば全ての例外をキャッチしてエラー用のレスポンスに変換したとしても、ユーザ側から見るとよくわからないエラーメッセージが表示されて困惑するだけ、ということにもなり得ます。
独自のドメイン例外 → HTTPのエラーレスポンスへの変換規則をしっかりと決めておいた方が良いでしょうね。

Controllerにあまり手間をかけたくない場合は、Laravelの例外ハンドラを独自に決めたルールに沿って改造する方法があります。
例えばドメインロジックではないですが、フォームリクエストはバリデーション失敗時に\Illuminate\Validation\ValidationExceptionという特定の例外を投げて、例外ハンドラでHTTPステータス422のレスポンスなどに変換しています。
同様に例外ハンドラにプロジェクト共通の例外の変換を任せる手法もよく見かけます。