📝
関数型ドメインモデリングから学ぶ「エラーの分類」
関数型ドメインモデリング を読んで、アプリケーションで扱うエラー／例外の整理方法が参考になったのでまとめます。
エラーの分類
アプリケーションで発生するエラーは大きく3つに分類できる。
1. ドメインエラー
- ビジネスプロセスの一部として想定されているエラー
- 例: 無効な製品コードを含む注文
- 他のドメインモデルと同様にモデル化し、ワークフロー内で処理する
2. パニック
- アプリケーションが処理不能となるシステムエラー
- 例: メモリ不足、null参照
- ワークフローから抜け出し、例外としてアプリケーション最上位でハンドリングすべき
3. インフラストラクチャエラー
- 実装上発生するが、ビジネスプロセス由来ではないエラー
- 例: ネットワークタイムアウト、認証失敗
- プログラム上の扱いはドメインエラーにもパニックにも寄せられるが、ビジネス的な取り扱いを検討できるため、ドメインエラーに近い扱いが有用な場合が多い
- 例: 製品コード検証サービスが利用できない場合、ビジネス的に迂回処理を設けるか、ユーザーに通知するかを検討する必要がある
- ドメインエキスパート/プロダクトオーナーに相談して検討した結果、ビジネスに組み込まれドメインエラーのような扱いになることがある
背景
C# で開発することが多いため、これまでは以下の組み込み例外を参考にして「システムエラー」と「アプリケーションエラー」に大別していた。
ただし、システムエラーの中にも以下のように性質の異なるものが混在していた。
- ネットワークタイムアウトのようにリトライ可能で処理継続できるもの
- null参照のように致命的で継続不能なもの（自分では Fatal Error と呼んで区別していた）
このため、従来の分け方ではしっくりこず、本書の分類は非常に参考になった。
補足：ドメインエラーとインフラストラクチャエラーの判別
エラーの分類で触れたように、インフラストラクチャエラーはドメインエラーのように扱いたいたい場面もあり、境界が曖昧になりやすい。
判別に迷う場合に、参考書籍では「ドメインエキスパートに相談すること」が推奨されていた。ただし、記載例の聞き方では単に「インフラストラクチャエラー」と片付けられてしまう可能性がありそうだと感じた。
実際の現場で使用する際には「ユーザーにどのような影響があるか」をドメインエキスパートも理解でしやすい言葉で説明した方が、ビジネスプロセスに組み込むかどうかを判断しやすくなると感じた。
Discussion