ありえない状態のオブジェクトが作られないよう、制約が適切に設定されているか？¶
Type: Structure
Category: ドメイン
Audience: 設計初心者 / 設計中のチーム / レビュワー
背景・概要¶
オブジェクトは生成された時点で「業務的に正しい状態」であるべき
後から制約チェックを別途書く方式はエラーが漏れやすく、複雑なロジックがばらけて保守困難になる。制約＝クラスの設計そのものと捉えるとよい
例¶
- Task(dueDate: Date, isCompleted: Boolean) のような生成時に成立する型制約を設計
- 専用のファクトリメソッドを介してのみ生成し、整合性違反を防ぐ
- EnumやSealed Classなどで状態の遷移範囲を明示（例：Draft → Submitted → Paid）
よくある失敗例¶
- 任意のフィールドをnull許容しすぎて、存在チェックがいたる所に必要
- status に存在しない値が入り、表示やロジック分岐でバグを生む
- ドメインに対する状態遷移の制限がなく、不正な操作がサーバーに通る
FAQ¶
Q. 制約は全て型で表現すべき？
A. 可能であれば型で保証する（Type-safe）のが理想。難しい場合はファクトリやコンストラクタでのバリデーションでもOK
Q. 状態の組み合わせが多い場合は？
A. 状態遷移図にして検討したり、状態ごとに専用クラスを分けて対応することも検討するとよい