ビジネスルール、ビジネスロジック、入力検証
これは1000回尋ねられるかもしれませんが、答えを見つけることができませんでした。ビジネスロジックのエラーをどのように処理するのでしょうか。私のビジネスモデルにニースAPIを実行しようとしています。一部のメソッドには非常に多くの検証がありますが、何か問題が発生した場合にどのように報告すればよいのでしょうか。 trueまたはfalseまたはnullを返しても、実際の原因が何であるかわからないことがあります。時々それは時々それは十分ではありません動作します。一部の人は例外を使用していると読みました。私はエラーメッセージを返すことができると思っていました。すべてがうまくいくと、それはnullになります。どういうわけかエラーコードは私のために追加されません。
あなたは正しい軌道に乗っています。ドメインまたはビジネスの検証ロジックは、trueまたはfalseを報告するだけではありません。ビジネスクラス（つまり、UIまたはログシステム）の "ユーザー"が、何かが間違っていることをエンドユーザーに報告するだけでなく、他のことを実行できるようにする必要があります。
今、それをどのように行うかは完全にあなた次第です。
決定：すべてを確認してから、すべてのエラー/警告/情報を報告するか、最初に遭遇したもので停止します。私は個人的に最初のものを選択し、UIに情報の使用方法を決定させます。ただし、トレードオフがあります。一部の検証には他の検証よりも時間がかかる場合があり、「単純な」検証が成功した場合にのみこれらをチェックすることをお勧めします。
これを行うために例外を使用することはありません。ほとんどの開発環境では、未処理の例外をユーザーに表示するための優れた方法があるため、一部の人々は例外を使用します。私はそれが悪い/怠惰な選択だと思います。そして、エラーがどこから来たのかを判断するのが難しいという理由だけでなく（スタックトレースはそこに役立つ可能性があります）、アプリが予測できない状態になり、エラーがさらに発生する可能性があるためでもありますデバッグはさらに困難です。
したがって、例外的な状況のために例外を予約する傾向があります。予想していなかったこと。バリデーションは私の意見ではそのカテゴリーに分類されません-あなたはすべての（現在の）バリデーションの懸念を予見しました、またはあなたはそれらに対してバリデートしなかったでしょう。
全体として、ドメイン/ビジネスクラスで検証をコーディングし、エラー/警告/ヒントインスタンスの配列（または私が使いたいもの）を収集します。それらは単純な文字列かもしれません、それらは完全に専門のクラスであることができます。通常、私は常にインスタンスを呼び出し元に返し、割り当てられていないポインターは返しません。 「有効」は、メッセージ数がゼロであることを示す単純なものです。
一部の人は例外を使用していると読みました。
理由があります。例外は例外的な状況を非常にうまく処理します。言語に例外がある場合は、それらを使用してください。
無効なデータは例外を発生させるはずです。
その後、アプリケーションはすべてのデータ検証例外を収集し、ユーザーに表示できます。
私はエラーメッセージを返すことができると思っていました。すべてがうまくいくと、それはnullになります。
適切な値を返す、または「ステータス」値（行null）を返す関数はお勧めできません。関数は常に適切な値を返すか、例外をスローする必要があります。
どういうわけか、エラーコードは私には合っていません。
エラー「コード」は非常に悪い考えであるためです。 Cプログラムを除いて、選択肢がほとんどありません。
PPPHP、
お読みになりましたか？ ドメイン駆動設計 ？この本には、ビジネスルールを分離するための優れたドメインモデルの開発に関するかなり良い資料があります。
プロジェクトのバグを修正するときは、その機能のユーザーストーリーを書き留めて、ユーザーの観点からどのように機能するかを理解します。たとえば、昨日、特定のコンボボックスに必要なデータが入力されていない場合にIllegalArgumentExceptionが発生するバグを修正していました。ユーザーはデバイスをリセットして再起動する必要があります。さて、この問題の修正は明白に思えるかもしれませんが、ユーザーストーリーは私の考えを明確にするのに役立ちました。私はその特定の例外を鎮静化し、コンボボックスに「データを利用できません」というテキストが含まれるようにしました。そのため、ユーザーがバグを報告したり、サポートに電話したりすると、問題がよりよく理解され、顧客にはあいまいなエラーメッセージが残されません。このような小さな調整は、顧客に対応するときに大きな違いをもたらすようです。
私は通常、成功フラグとメッセージのリストの両方を使用します。各メッセージは、コードとフリーフォームメッセージの両方で構成されています。メッセージを含む正常な応答を受け取った場合、メッセージはすべて警告であり、サーバー側で何かが発生したことがわかります。
コードとメッセージの両方を使用する理由は、メッセージを人間の読者に表示できるが、コードはソフトウェアで処理できるためです。このように、フリーフォームメッセージが変更された場合、そのエラーを処理するソフトウェアも変更する必要はありません。
当然、人間以外の回答が読めないことが確実な場合は、コードを忘れてもかまいませんが、後で元に戻すのは難しい決定です。