🔥
不整合なデータが発生しないように、適切なバリデーションが行われているか？
不整合なデータが発生しないように、適切なバリデーションが行われているか？
背景・概要
入力値や状態遷移をバリデーションせずに許容すると、後続処理やDBに**「業務的にありえないデータ」が残り、重大な障害の温床になる**
**「いつ・どこで・どんなバリデーションを行うか」**を設計段階で定めることが重要
例
- ドメインオブジェクトのコンストラクタやファクトリで整合性チェックを実施
- アプリケーション層でユースケースごとに適切な制約を追加（例：金額が正数であるなど）
- バリデーションエラーは理由つきでユーザーにフィードバックされる
よくある失敗例
- 「未承認なのに支払い済み」など、状態不整合なデータがDBに存在
- 必須項目のチェックがフロントのみにあり、APIから直接操作で不正状態が生成される
- エラー時の例外ハンドリングが未整理で、どこで失敗したか分からない
FAQ
Q. バリデーションの粒度はどの層でやるべき？
A. 形式的なチェック（空/文字列/数値）はアプリ層、業務ルールはドメイン層に置くのが一般的。冗長にならないよう整理が必要
Q. 全てのフィールドにバリデーション必要？
A. 優先度をつけて、業務的に破綻するもの（整合性が壊れるもの）から対応するとよい
関連観点
- ドメインオブジェクトが適切に抽象化され、アプリケーション層と適切に分離されているか？
- ありえない状態のオブジェクトが作られないよう、制約が適切に設定されているか？
- データのライフサイクル（作成・更新・削除）が明確か？
- 一貫性を担保するための分散トランザクションの必要性が整理されているか？
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：🏷️ドメイン
レベル：Structure（構造・原則・責務整理レベル）
推奨読者：設計初心者 / 設計中のチーム / レビュワー
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion