バリデーション解体新書 - kawasima

バリデーション解体新書 2025/4/8に開催した #アーキ部 『バリデーション解体新書』の内容を編集したものです。 バリデーションとは何か? 広義には、 何らかの処理を実施するにあたって、入力データが想定する条件を満たすかを検証する行為 と言える。 この定義で、アプリケーションのどこでバリデーションをしているのかを考えると、以下のように各層にそれが見られる。 このように実装される場所が散らばるので、「バリデーション」や「入力チェック」を分類して開発ガイドラインを作ることが多い。 例えば、大規模Java開発向けのTERASOLUNA開発ガイドラインを見てみると、 ユーザーが入力した値が不正かどうかを検証することは必須である。 入力値の検証は大きく分けて、 1. 長さや形式など、文脈によらず入力値だけを見て、それが妥当かどうかを判定できる検証 2. システムの状態によって入力値が妥当かどうか

[rzi]

入力時のバリデーション超重要。実感としても、不具合の原因が 想定してなかった入力値だったのってすごく多い。 その次に重要なのが出力、出力値についても厳密にValid設計すべき

[yasuharu519]

always-valid な layer について

[tmatsuu]

よい

[kiririmode]

レイヤ間、tier間のバリデーションの考え方。always valid layerを作るのが初手で、そのvalidを定義するのがドメインモデリングの一つ

[nil0303]

Javaみたいな言語だと数値の要素に文字列突っ込まれるとそもそも処せないので入力値時点で弾くしか無くなる。とりあえず全部の値を受け入れてmodelで弾くのはRailsとかの思想。いわゆる型の有無でも変わってくる。

[matarillo]

なるほど、Wlaschinもそういうこと言われたから https://fsharpforfunandprofit.com/transactionscript/ ってなったのか

[katsyoshi]

10年前バリデーションナイトで聞いたやつだ！！！

[BOOOOOOOON]

>(TERASOLUNAのガイドのように「再利用しない」というのも一案ではあるが…) 通常の対策としては業務ロジックでも、事前条件を明記しバリデーションを同様に実装することである。　言うほど「通常の対策」？？？？？？

[xlc]

入力時のバリデーションと出力時のエスケープを「サニタイズ」とか言ってごちゃ混ぜにしている人は多い。私自身は入力チェックはせず(エラーとしない)「善きに計らう」実装を心がけてる。

[turanukimaru]

これはDDDではなくトランザクションスクリプトで、入力値をバリデーションしつつコントローラごとに業務ロジックと入力チェックを作るので悲惨なことになる。入力値から構築する集約＝ドメインモデルをValidにするべき

[s-nanagi]

面白い考察で、『Domain Modeling Made Functional』でも似たようなことはしてるけど若干ニュアンスが違うので併せて読むのが良いかもしれない。和訳版も出たし。

[t-murachi]

なんか色んな話が混じっているようにも思えるが… ひとつひとつは割と大事な話だと思う。銀の弾丸はない。

[FreeCatWork]

バリデーション？難しいにゃ！ ボクにはお膝の上があればいいにゃ！

[hamamuratakuo]

バリデーションは形式と意味の2種類があり、責務の明確化と多層での実装がシステムの健全性に不可欠。業務上Validなデータを定義するところから始める方が結果的に簡単で安全。

[bopperjp]

クソ面白そう。あとで絶対読む。

[razokulover]

“このようにレイヤーを分けているにも関わらず、上位レイヤーに呼び出すデータは、下位レイヤーの事前条件を満たすようバリデーション済みであることを暗黙的な呼び出し条件にしてしまうことになる。”

[hirorinya]

なるほど、わかりやすい