BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//https://techplay.jp//JP
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALDESC:バリデーション解体新書
X-WR-CALNAME:バリデーション解体新書
X-WR-TIMEZONE:Asia/Tokyo
BEGIN:VTIMEZONE
TZID:Asia/Tokyo
BEGIN:STANDARD
DTSTART:19700101T000000
TZOFFSETFROM:+0900
TZOFFSETTO:+0900
TZNAME:JST
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:977193@techplay.jp
SUMMARY:バリデーション解体新書
DTSTART;TZID=Asia/Tokyo:20250408T213000
DTEND;TZID=Asia/Tokyo:20250408T230000
DTSTAMP:20260528T024020Z
CREATED:20250325T140528Z
DESCRIPTION:イベント詳細はこちら\nhttps://techplay.jp/event/97719
 3?utm_medium=referral&utm_source=ics&utm_campaign=ics\n\n基本的にア
 ーキ部は私kawasimaの興味を惹いたテーマについて滔々
 と語る会です。\n内容\nデータの検証の意味での「バリ
 デーション(入力チェック)」は、標準としての定義が
 なく、人によって指すものが違うことがあるようです
 。また、バリデーションに付随したエラーメッセージ
 の扱いや、一度にどこまで検証するかの範囲の違いな
 どで、また認識が合わないことがあるようです。\n私
 が好んで使うのは、KhorikovさんのAlways-valid-Domain Modelに
 ある定義ですが、これもドメイン層の認識が人によっ
 て異なる状況だと、やはり話が通じないことがありま
 す。\nhttps://enterprisecraftsmanship.com/posts/always-valid-domain-mod
 el/\nバリデーションには、そこに含意される処理の種
 類の範囲と付帯することが期待されている役割にいく
 らかバリエーションがあることを認めつつ、それらの
 差異が生まれるポイントを整理してみようと思います
 。\n\nフロントエンドでバリデーションしていれば、バ
 ックエンドでのバリデーションは不要なのか?\nそこで
 いうバリデーションって何?\nSIerによくみられる分類(
 単項目チェック、複合項目チェック、ビジネスロジッ
 クチェック)ってどうなの?\nバリデーションは誰のため
 に?\nV&Vと関係ある?\nParse don't validateとAlways-valid Domain Mod
 el\n\n注意事項など\n\nGoogle MeetのURLを開始1時間くらい前
 にこのページの「参加者への情報」欄に記載しますの
 で、そこからアクセスしてください。\n途中、ご意見
 、ツッコミなどあれば、どんどん割り込んでいただい
 て構いません。\n途中抜け、寝落ちはご自由に。\n
LOCATION:Google Meet
URL:https://techplay.jp/event/977193?utm_medium=referral&utm_source=ics&utm
 _campaign=ics
END:VEVENT
END:VCALENDAR