広告
募集内容 |
Meet参加 無料
先着順
|
---|---|
申込者 | 申込者一覧を見る |
開催日時 |
2025/04/08(火) 21:30 ~ 23:00
|
募集期間 |
2025/03/25(火) 16:33
〜 |
会場 |
Google Meet |
出席登録 |
(イベント開始時間の2時間前から終了時間まで、参加者のみに公開されます)
|
イベントの説明
基本的にアーキ部は私kawasimaの興味を惹いたテーマについて滔々と語る会です。
内容
データの検証の意味での「バリデーション(入力チェック)」は、標準としての定義がなく、人によって指すものが違うことがあるようです。また、バリデーションに付随したエラーメッセージの扱いや、一度にどこまで検証するかの範囲の違いなどで、また認識が合わないことがあるようです。
私が好んで使うのは、KhorikovさんのAlways-valid-Domain Modelにある定義ですが、これもドメイン層の認識が人によって異なる状況だと、やはり話が通じないことがあります。 https://enterprisecraftsmanship.com/posts/always-valid-domain-model/
バリデーションには、そこに含意される処理の種類の範囲と付帯することが期待されている役割にいくらかバリエーションがあることを認めつつ、それらの差異が生まれるポイントを整理してみようと思います。
- フロントエンドでバリデーションしていれば、バックエンドでのバリデーションは不要なのか?
- そこでいうバリデーションって何?
- SIerによくみられる分類(単項目チェック、複合項目チェック、ビジネスロジックチェック)ってどうなの?
- バリデーションは誰のために?
- V&Vと関係ある?
- Parse don't validateとAlways-valid Domain Model
注意事項など
- Google MeetのURLを開始1時間くらい前にこのページの「参加者への情報」欄に記載しますので、そこからアクセスしてください。
- 途中、ご意見、ツッコミなどあれば、どんどん割り込んでいただいて構いません。
- 途中抜け、寝落ちはご自由に。
資料 資料をもっと見る/編集する
資料が投稿されると、最新の3件が表示されます。
広告