例外を伴うビジネスルールの表現
私はそれが高価であることを知っていますが、（IMO）それは非常に良い習慣だと思います。私が言うようなルールについて話している、あなたが営業担当者でない場合、あなたは請求書を保存できない...その場合、「あなたは許可されていません」などと例外を投げる...
別のアプローチは、ステータスまたはそのようなものを持つオブジェクトを持つことです
他のアプローチはありますか？それについてどう思いますか？
例外を含む個々のビジネスルールチェックを表すつもりなら、それは非常に良い考えではないと思います。多くの場合、複数の失敗した状態を報告する必要があり、最初の状態で停止することはありません。
一方で、allルールとthenをチェックして、概要で例外をスローすることは良い習慣だと私は確信しています。
あなたが私たちに与えた例では、例外を発生させることは悪い考えだと思います。ユーザーが作業を開始する前にユーザーが承認されていないことがわかっていて、ユーザーが何らかの機能を実行することを許可し、ユーザーがタスクを既に完了した後にメッセージを表示する場合、それは単に悪い設計です。
例外を使用してビジネスルールを適用することは、良い設計ではありません。
優れたビジネスロジックを作成する上で、例外をスローすることの価値がわかりません。システムの運用における予期しない状況に対処することを目的としたシステムの使用を含まないビジネスロジックの処理には、数十のアプローチがあります。
expectedは、ビジネスロジックでは条件が満たされないことです。それがそもそもそれを持っている理由であり、予期しないI/Oエラー、メモリ不足エラー、null参照を処理する同じメカニズムに便乗したくありません。これらはシステムの障害ですが、満たされていないビジネス条件を検出することは、システムの正常な動作です。
さらに、それは意図しない結果に対応できるシステムです。ある時点で例外をキャッチする必要があるため、新しいビジネスルールの例外が意図しない場所でキャッチされたり、ビジネスルールを探すコードが実際には意味のない例外をキャッチしたりする可能性があります。それのための。はい、これらの条件は適切なコーディングプラクティスで説明できますが、複数の開発者が作業している重要なシステムではミスが発生し、コストのかかるミスにならないことを期待する必要があります。
ビジネスルールを表現することと、それらを実装することは別です
ユーザーエクスペリエンスについて考えます。ユーザーが営業担当者ではない場合、「請求書を作成する」というボタンを与えるまったく？
それは完全に何が行われているかに依存します。
まず、あなたが望む実際の行動は何ですか？誰かが自分の情報を入力している場合、拒否して、基本的に「それはできない」というダイアログボックスが正しいでしょう。これがデータ入力担当者であり、フォームの山から作業している場合、ダイアログボックスもおそらく有効であり、データ入力担当者は無効なフォームを特別な山に配置できます。バッチ処理を実行している場合は、停止するのではなく、フラグを立てて次の処理に進みます。
動作を取得したら、それを実装する方法を決定する必要があります。例外をスローするビジネスルールチェッカーを使用することは、おそらく良い考えです。戻りコードを返し、それを渡すことは、問題が発生する可能性のある他の何かであり、間違いのあるエントリーがさらに進むことを望んでいません。
パフォーマンスの費用について心配する必要はありません。個人がデータを入力する場合、関係する他の時間と比較してそれは取るに足らないことです。通常、人間はそのシステムで最も時間がかかります。バッチジョブの場合、例外がパフォーマンスの問題であると、不良レコードが多すぎるため、実際にはそれらすべての処理と再入力が例外よりも問題になります。
一貫性のある堅牢で適切に設計された例外APIを持つことは非常に適切です。これを使用してビジネスルールを適用することも適切な場合があります。実際、私の経験では、ビジネスルールが複雑になるほど、この方法で処理される可能性が高くなります。権限のある分岐ロジックを作成するよりも、例外が予想されるシステムを作成する方が簡単ではありません。
つまり、単一の文で記述できる単純なルールは、一般的に、どちらがそうであるかに応じて、予防的または信頼できる方法で実装する必要があります。ただし、多次元のルールで3つまたは4つ以上の要素が必要な場合（特に、これらの要素の選択が他の1つ以上の要素に基づいている場合）は、例外コーディングの保守性が向上します。多くの場合、これらの場合、ロジックパスにはスローする必要のある多くの先行例外があります（アクションを実行できない理由を確認します）。その後（またはその逆）、セキュリティへのフォールスルーがあります（アクションが許可されていることを確認します）。 ）、時には、チェックする必要がある信頼できる蓄積ロジック（子孫/祖先の可用性、オブジェクトを配置する必要のある前駆状態など）がある場合があります。その後、ロジックは、より直接的な信頼できるものを含む実際のプロセスに移行します。ロジックは、プロセスに直接関連するチェックを行います。
このタイプの例外スローから派生する1つの利点は、プロジェクトの複数の領域にわたって、先行する例外を分離して再利用できることです。 （これは、アスペクト指向プログラミングの本質です。）これにより、一般的なビジネスルールの特定の側面を、自己完結型で保守可能なコンポーネントにカプセル化します。一般に、これらのコンポーネントは、スローされたエラーメッセージと1-1で対応します。 （複数の異なる例外をスローするコンポーネントが1つある場合もありますが、複数のコンポーネントから同じ例外がスローされることはほとんどないはずです。）
私の意見では、すべてのNレベルで例外プロセスを構築する必要があるため、例外ベースのシステムを設計することはより難しく、初期開発時間は長くなります。しかし、これらのシステムは一般的にはるかに安定しています。 「失敗しない」システムを設計することは決して不可能ですが、例外ベースの設計の利点は、常に失敗を予測していることです。ほとんどの人にとって、プロセスは直感に反するものです。それは、道を尋ねたり、電源を入れてはいけないすべての道を誰かに教えたりするようなものです。