DDDで例外を処理する方法

最近のDotNext 2018カンファレンスで、ドメインドリブンデザインのBoFが開催されました。 それは、白熱した議論を引き起こした例外を扱う問題に対処しましたが、それが主要なトピックではなかったので、詳細な議論を受け取りませんでした。



また、スタックオーバーフローに関する質問から有料アーキテクチャコースで終わるまで、多くのリソースを研究すると、ITコミュニティが例外とその使用方法に対して曖昧な態度を持っていることがわかります。



ほとんどの場合、例外を使用すると、 goto演算子セマンティクスを持つ実行スレッドを簡単に構築でき、コードの可読性に悪影響を与えると言われています。



独自の種類の例外を作成するか、.NETで提供される標準的な例外を使用するかについて、さまざまな意見があります。



誰かが例外の検証を行い、どこでも誰かがResultモナドを使用します。 Resultを使用すると、メソッドシグネチャによって、実行が成功しただけではないかどうかを理解できます。 しかし、命令型言語（C＃を含む）では、Resultが広く使用されているため、コードが読みにくくなり、言語構造が攻撃されるため、元のスクリプトを作成するのは困難です。



この記事では、私たちのチームが採用しているプラ​​クティスについて説明します（要するに、私たちはすべてのアプローチを使用していますが、いずれもドグマではありません）。



ASP.NET MVC + WebAPIに基づいて構築されたエンタープライズアプリケーションについてです。 アプリケーションはタマネギアーキテクチャで構築され、データベースおよびメッセージブローカーと通信します。 ELKスタックへの構造化されたロギングを使用し、Grafanaによる監視が設定されます。



次の3つの観点から例外の処理を検討します。

1. 一般的な例外規則
2. 例外、エラー、およびタマネギのアーキテクチャ
3. Webアプリケーションの特殊なケース

一般的な例外規則

1. 例外とエラーは同じものではありません。 例外については、エラーについては例外を使用します-結果。
2. 例外は例外的な状況にのみ当てはまり、定義上、多くの場合はそうすることはできません。 したがって、例外が少ないほど優れています。
3. 例外処理はできるだけ細かくする必要があります。 リヒターが彼の記念碑的な作品で書いたように。
4. エラーを元の形式でユーザーに配信する必要がある場合は、結果を使用します。
5. 例外は、システムの境界を元の形のままにしないでください。 これはユーザーフレンドリーではなく、攻撃者がシステムの潜在的な弱点をさらに調査する方法を提供します。
6. スローされた例外がアプリケーションによって処理される場合、例外ではなくResultを使用します。 例外の実装はgoto演算子によって隠され、さらに悪いことに、処理コードが例外スローコードから遠くなります。 結果は、エラーの可能性を明示的に宣言し、その「線形」処理のみを許可します。

例外、エラー、およびタマネギのアーキテクチャ

次のセクションでは、次のレイヤーの例外/エラーをスロー/処理する責任とルールを検討します。

• アプリケーションホスト
• インフラ
• アプリケーションサービス
• ドメインコア

アプリケーションホスト

責任は何ですか

• コンポジションのルート 。アプリケーション全体の動作をカスタマイズします。
• 外の世界との相互作用の境界は、ユーザー、他のサービス、予定されている起動です。

これらは非常に複雑な責任であるため、自分自身を制限する価値があります。 残りの責任は内層に与えます。



結果からエラーを処理する方法



適切な形式（たとえば、http応答）に変換して、外部にブロードキャストします。



結果の生成方法



まさか。 このレイヤーにはロジックが含まれていないため、エラーを生成する場所はありません。



例外を処理する方法

1. 詳細を非表示にして、外部への送信に適した形式に変換します
2. ログインします。

例外をスローする方法



まさか、この層は最も外部であり、ロジックを含んでいません-例外をスローする人はいません。

インフラ

責任は何ですか

1. ポートへのアダプター 、または単純にドメインインターフェースを実装し、インフラストラクチャ（サードパーティサービス、データベース、アクティブディレクトリなど）へのアクセスを提供します。このレイヤーは、できるだけ愚かで、できるだけロジックを少なくする必要があります。
2. 必要に応じて、 腐敗防止レイヤーとして機能できます。

結果からエラーを処理する方法



Resultモナドで実行されているデータベースやその他のサービスのプロバイダーがわかりません。 ただし、一部のサービスは戻りコードで動作します。 この場合、ポートに必要な結果形式に変換します。



結果の生成方法



一般的な場合、このレイヤーにはロジックが含まれていないため、エラーは生成されません。 ただし、破損防止レイヤーとして使用する場合は、さまざまなオプションが可能です。 たとえば、レガシーサービスからの例外を解析し、単純な検証メッセージである例外を結果に変換します。



例外を処理する方法



一般的な場合、必要に応じて、詳細を保護してさらにスローします。 実装されているポートがResultをコントラクトに返すことを許可している場合、インフラストラクチャは、処理可能な例外のタイプをResultに変換します。



たとえば、プロジェクトで使用されるメッセージブローカーは、ブローカーが利用できないときにメッセージを送信しようとすると例外をスローします。 アプリケーションサービスレイヤーはこの状況に対応しており、再試行ポリシー、サーキットブレーカー、または手動のデータロールバックで処理できます。



この場合、アプリケーションサービスレイヤーは、エラーの場合に結果を返すコントラクトを宣言します。 また、インフラストラクチャ層はこのポートを実装し、ブローカーからの例外を結果に変換します。 当然、特定の種類の例外のみを変換し、すべてを連続して変換するわけではありません。



このアプローチを使用すると、2つの利点が得られます。

1. 契約の誤りの可能性を明示的に宣言します。
2. 特定のメッセージブローカーから抽象化されているため、アプリケーションサービスがエラーの処理方法を知っているが、例外の種類を知らない状況を取り除きます。 基本System.Exceptionにcatchブロックを構築するということは、アプリケーションサービスが処理できる例外だけでなく、すべての種類の例外をキャッチすることを意味します。

例外をスローする方法



システムの詳細に依存します。



たとえば、存在しないデータを要求すると、SingleおよびFirst LINQステートメントはInvalidOperationExceptionをスローします。 ただし、このタイプの例外は.NETのすべての場所で使用されるため、細かく処理することはできません。



私たちのチームは、カスタムItemNotFoundExceptionを作成し、要求されたデータが見つからず、ビジネスルールに従ってそうでない場合はインフラストラクチャレイヤーからそれをスローするという慣行を採用しています。



要求されたデータが見つからず、これが許容される場合は、ポートコントラクトで明示的に宣言する必要があります。 たとえば、 Maybeモナドを使用します。

アプリケーションサービス

責任は何ですか

1. 入力データの検証。
2. サービスのオーケストレーションと調整-トランザクションの開始と終了、分散スクリプトの実装など。
3. ポートを介してドメインオブジェクトと外部データをインフラストラクチャにダウンロードし、その後ドメインコアでコマンドを呼び出します。

結果からエラーを処理する方法



ドメインコアからのエラーは、外部の世界にそのまま変換されます。 インフラストラクチャからのエラーは、再試行、サーキットブレーカー、または外部へのブロードキャストを通じて処理できます。



結果の生成方法



結果として検証を実装できます。



操作の部分的な成功に関する通知を生成できます。 たとえば、「注文は正常に送信されましたが、配送先住所の確認中にエラーが発生しました。 スペシャリストがすぐにご連絡し、配達の詳細を明確にします。



例外を処理する方法



アプリケーションが処理できるインフラストラクチャ例外は、インフラストラクチャ層によってすでに結果に変換されていると仮定すると、まったく処理しません。



例外をスローする方法



一般的にはありません。 しかし、記事の最後のセクションで説明されている境界線オプションがあります。

ドメインコア

責任は何ですか



ビジネスロジックの実装、システムの「コア」、およびその存在の主な意味。



結果からエラーを処理する方法



レイヤーは内部にあり、同じドメイン内のオブジェクトからのみエラーが発生する可能性があるため、ビジネスルールまたは元の形式でのエラーの上位変換に処理が削減されます。



結果の生成方法



ドメインコアにカプセル化され、アプリケーションサービスレベルでの入力データの検証でカバーされないビジネスルールに違反する場合。 一般に、このレイヤーでは、結果が最も頻繁に使用されます。



例外を処理する方法



まさか。 インフラストラクチャの例外はインフラストラクチャレイヤーによって既に処理されており、データは既に到着し、アプリケーションサービスレイヤーのおかげで構造化され、完全で、検証されています。 したがって、飛び出す可能性のあるすべての例外は本当に例外になります。



例外をスローする方法



通常、ここでは一般的なルールが機能します。例外が少ないほど良いです。



しかし、コードを書いて、特定の条件下ではひどいビジネスができることを理解する状況になったことはありますか？ たとえば、お金を2回償却したり、データを台無しにしたりすると、骨を収集できません。



原則として、オブジェクトの現在の状態に対して無効なコマンドの実行について話します。



もちろん、UI上の対応するボタンはこの状態では表示されません。 この状態では、バスからコマンドを受け取るべきではありません。 外側の層とシステムがそれらの機能を正常に実行するならば、これはすべて本当です。 しかし、ドメインコアでは、外部層の存在について知る必要はなく、それらの作業の正確性を信じる必要があります。システムの不変条件を保護する必要があります。



一部のチェックは、検証レベルでアプリケーションサービスに配置できます。 しかし、これは防御的なプログラミングに変わる可能性があり、極端な場合には以下につながります：

1. 特定の不変条件を外側の層で検証する必要があるため、カプセル化は弱められます。
2. サブジェクト領域の知識は外側の層に「流れ込み」、チェックは両方の層で複製できます。
3. 外部層からのコマンドの実行の検証は、ドメインオブジェクトが現在の状態でコマンドを実行できないことを検証するよりも複雑で信頼性が低い場合があります。

また、このようなチェックを検証レイヤーに配置する場合、ユーザーにエラーの理由を伝える必要があります。 現在の状況ではまったく実行できない操作について話しているため、次の2つの状況のいずれかに陥るリスクがあります。

• 「予期しないエラーが発生しました」というメッセージのように、普通のユーザーにはまったく理解できず、とにかくサポートに行くというメッセージを与えました。
• 私たちは、彼が実行したい操作を実行できず、他の回避策を探すことができる理由を、わかりやすい形で悪役に伝えました。

しかし、記事のメイントピックに戻ります。 すべての兆候により、議論中の状況は例外的です。 それは決して起こるべきではありませんが、もしそうなら、それは悪いでしょう。



この状況では、例外をスローし、必要な詳細を誓約し、「操作は実行できません」という一般形式のエラーをユーザーに返し、このタイプのエラーの監視を設定し、それらが表示されないことを期待するのが最も論理的です。



この場合に使用する例外のタイプは何ですか？ 論理的には、これは別のタイプの例外である必要があります。これにより、他の例外と区別でき、外部層からの例外処理によって誤ってキャッチされないようにするためです。 階層や多くの例外も必要ありません。本質は同じです-受け入れられないことが起こりました。 プロジェクトでは、このためにCorruptedInvariantException型を作成し、適切な状況で使用します。

Webアプリケーションの特殊なケース

他のWebアプリケーション（デスクトップ、デーモン、Windowsサービスなど）との大きな違いは、短期的な操作（HTTPリクエストの処理）の形での外部とのやり取りです。その後、アプリケーションは発生したことをすぐに「忘れ」ます。



また、要求を処理した後、応答が常に生成されます。 コードによって実行された操作がデータを返さない場合でも、プラットフォームはステータスコードを含む応答を返します。 操作が例外によって中止された場合、プラットフォームは対応するステータスコードを含む応答を返します。



この動作を実装するために、Webプラットフォームでのリクエスト処理はパイプライン（パイプ）の形式で構築されます。 最初に、要求が順番に処理され（要求）、次に応答が準備されます。



ミドルウェア、アクションフィルター、httpハンドラーまたはISAPIフィルター（プラットフォームに応じて）を使用し、任意の段階でこのパイプラインに統合できます。 そして、リクエスト処理のどの段階でも、処理を中断することができ、パイプラインは応答を形成するために進みます。



原則として、パイプラインアーキテクチャにアプリケーションのビジネス部分を実装するのではなく、操作を順次実行するコードを記述します。 また、このアプローチでは、リクエストの実行を中断してすぐにレスポンスの形成に進む場合、シナリオを実装するのが少し難しくなります。



これは例外処理と何の関係があるのでしょうか？



実際、この記事の前の部分で説明した例外を処理するための規則は、このシナリオにうまく適合していません。



例外はgotoセマンティクスであるため、使用するのは適切ではありません。



Resultの広範な使用は、アプリケーションのすべてのレイヤーにドラッグ（Result）するという事実につながり、応答を形成するときに、どのステータスコードを返すかを理解するために、何らかの方法でResultを解析する必要があります。 また、この解析コードを一般化してミドルウェアまたはActionFilterにプッシュすることをお勧めします。これは別の冒険になります。 つまり、Resultは例外よりもはるかに優れたものではありません。



そのような状況で何をすべきか？



絶対ビルドしないでください。 私たちは、自分の利益のためにルールを設定します。



継続できないために操作を中止したい場合、例外をスローしてもgotoセマンティクスはありません。 実行は出口に向けられ、ビジネスコードの別のブロックには向けられません。



目的のステータスコードを決定するために中断の理由が重要な場合は、カスタム例外タイプを使用できます。



前に、使用する2つのカスタムタイプ、ItemNotFoundException（404に変換）とCorruptedInvariant（500に変換）について説明しました。



ユーザーがロールモデルまたはクレームに該当しないため、ユーザーの権利を確認する場合は、カスタムForbiddenException（ステータスコード403）を作成することができます。



そして最後に、検証。 ユーザーがリクエストを変更するまで何もできません。このセマンティクスはコード422で記述されています 。 そのため、操作を中断し、リクエストを直接出口に送信します。 これは、例外を使用して行うこともできます。 たとえば、 FluentValidationライブラリには、要求の問題をユーザーに明確に表示するために必要なすべての詳細をクライアントに渡す組み込み型の例外が既にあります。



以上です。 例外をどのように処理しますか？