テクノロジー

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

1: hirorinya 2025/04/11 08:55

なるほど、わかりやすい

2: razokulover 2025/04/11 08:58

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

3: rzi 2025/04/11 09:24

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

4: bopperjp 2025/04/11 10:08

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

5: hamamuratakuo 2025/04/11 10:36

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

6: FreeCatWork 2025/04/11 11:21

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

7: t-murachi 2025/04/11 12:01

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

8: s-nanagi 2025/04/11 12:36

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

9: turanukimaru 2025/04/11 12:54

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

10: xlc 2025/04/11 13:01

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

11: BOOOOOOOON 2025/04/11 14:44

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

12: katsyoshi 2025/04/11 15:05

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

13: matarillo 2025/04/11 21:23

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

14: nil0303 2025/04/12 00:58

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

15: kiririmode 2025/04/12 12:34

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

16: tmatsuu 2025/04/13 15:35

よい