不整合なデータが発生しないように、適切なバリデーションが行われているか？¶
Type: Structure
Category: ドメイン
Audience: 設計初心者 / 設計中のチーム / レビュワー
背景・概要¶
入力値や状態遷移をバリデーションせずに許容すると、後続処理やDBに「業務的にありえないデータ」が残り、重大な障害の温床になる
「いつ・どこで・どんなバリデーションを行うか」を設計段階で定めることが重要
例¶
- ドメインオブジェクトのコンストラクタやファクトリで整合性チェックを実施
- アプリケーション層でユースケースごとに適切な制約を追加（例：金額が正数であるなど）
- バリデーションエラーは理由つきでユーザーにフィードバックされる
よくある失敗例¶
- 「未承認なのに支払い済み」など、状態不整合なデータがDBに存在
- 必須項目のチェックがフロントのみにあり、APIから直接操作で不正状態が生成される
- エラー時の例外ハンドリングが未整理で、どこで失敗したか分からない
FAQ¶
Q. バリデーションの粒度はどの層でやるべき？
A. 形式的なチェック（空/文字列/数値）はアプリ層、業務ルールはドメイン層に置くのが一般的。冗長にならないよう整理が必要
Q. 全てのフィールドにバリデーション必要？
A. 優先度をつけて、業務的に破綻するもの（整合性が壊れるもの）から対応するとよい