「すべての非サードパーティコード」ではない場合、実際には「ビジネスロジック」とはどういう意味ですか？

職場やオンラインでビジネスロジックについて多くの人が話しているのを聞いたことがあり、このサイトに関するいくつかの質問を読んだことがありますが、この用語はまだあまり意味がありません。たとえば、私がよく見かける（言い換え）ステートメントは次のとおりです。

• 「ビジネスロジックは、実際のビジネスルールをエンコードするプログラムの一部です。」私が読んだ定義のほとんどは、このような円形のものです。

• 「ビジネスロジックは、特定のアプリケーションに固有のすべてです。」「特定のアプリケーションはビジネスロジック以外の何物でもない」と、これがどのように異なるかはわかりません。したがって、質問のタイトル。

• 「データアクセス層の上とGUI層の下にビジネスロジック層が必要です。」私が書いたコードでは、データベースアクセサーはアクセスするデータを知る必要があり、UIコードはそれを正しく表示するために表示するものについて多くを知る必要があり、その間に実際に行うことは何もありませんクライアントとサーバー間でデータの塊を渡すこと以外の2つの場所。それでは、実際にビジネスロジックレイヤーに入るものは何でしょうか？

• 「ビジネスロジックはプレゼンテーションロジックから分離する必要があります。」私たちが受け取る機能要求のほとんどは、ビジネス上の理由でプレゼンテーションロジックを変更することです。ビジネスルールの1つが、デフォルトで32番目の表記で米国国債の価格を表示する場合（ユーザーに構成するためのUIも提供します）、プレゼンテーションロジックは、このルールが完全に実装されていない場合、少なくとも存在することを知る必要があります。また、UXデザインの主要な部分は、ユーザーがソフトウェアが実装しようとしているビジネスルールを理解するのを支援しているようです。

実際にビジネスロジックのみを行うチームに所属していて、非ビジネスロジックはすべて他のチームによって実行されている可能性はありますか？または、個別のエンティティとしての「ビジネスロジック」の概念全体は、特定のアプリケーションまたはアーキテクチャでのみ機能しますか？

答えを具体的にするために：ドミノのピザアプリを再実装する必要があると仮定します。ビジネスロジックとは何ですか？また、そのアプリの非ビジネスロジックとは何ですか？そして、ピザ情報のほとんどがデータアクセス層とプレゼンテーション層に流出することなく、ピザの注文ビジネスロジックを独自のコードの「層」に配置するにはどうすればよいでしょうか。

更新：私のチームはおそらく90％のUIコードを実行しており、ビジネスロジックと呼ばれるものの大部分（すべてではない）が他のチームまたは企業から来ているという結論に達しました。基本的に、私たちのアプリケーションは監視用です財務データ、およびほとんどすべての機能は、ユーザーが表示するデータと表示方法をカスタマイズする方法です。売買は行われていません（ただし、当社の他のアプリと少し統合しています）が、実際のデータは外部ソースの負荷によって提供されます。しかし、ユーザーは自分の「モニター」のコピーを他のユーザーに送信するなどのことを許可しているので、私たちがそれをどのように処理するかの詳細は、おそらくビジネスロジックとみなされます。実際には、現在バックエンドコードの一部と通信するモバイルアプリがあり、フロントエンドコードのどの部分を理想的な世界（基本的には準MVCのM）でUIと共有したいかを正確に知っています。それが私たちにとってのBLLだと思います。

user61852の答えは、「ビジネスロジック」が何を参照し、何を参照していないかについて、より具体的な理解を与えてくれたので受け入れています。

ゲームやグラフィックを多用するアプリの経験があまりないため、CRUDアプリケーションに関するヒントをいくつか紹介します。

• 通常、ビジネスロジックには、たとえば「クライアントが最後のクレジットの支払いを完了していない場合、新しいクレジットを拒否する」、「朝食を販売しない」など、ビジネスの所有者が長年にわたって学習または決定したルールが含まれます「午前11時を過ぎて」、または「月曜日と火曜日、顧客は1つの価格で2つのピザを購入できます」。
• もちろん、プレゼンテーションレイヤーは、割引の利用可能性、またはクレジットが拒否された理由を示すメッセージを表示する必要がありますが、そのようなレイヤーはそれらのことを決定するのではなく、ユーザーに内部で発生したことを伝えるだけです。
• 通常、ビジネスロジックにはワークフローが含まれます。たとえば、「このアイテムは、マネージャーが3営業日以内に承認するか、顧客が必要なドキュメントを提出していない場合は「情報の要求」ステージに入れる必要があり、アイテムは拒否されます」。
• プレゼンテーション層は通常、そのようなワークフローを処理せず、ワークフローの状態のみを反映します。
• また、ビジネスロジックによって既に決定が下されているため、データアクセス層は通常簡単です。たとえば、MS SQL ServerからOracleにデータを移行する場合、このレイヤーは影響を受けます。
• GUIがサーバーへの呼び出しを避けるために検証を行うこともありますが、それは慎重に行う必要があります。そうしないと、そのレイヤーに多くのビジネスロジックを含めることができます。
• 混乱の多くは、アプリケーションでは懸念事項が分離されておらず、事実上、プレゼンテーションレイヤーのビジネスロジックが多すぎるという事実から生じている可能性があります。アプリケーションレイヤーまたはデータアクセスレイヤーに（間違って）ビジネスロジックがあるという事実は、それがビジネスロジックであるという事実をまったく変えません。
• マイル/ヤード/フィートの代わりに距離をメートル法で表示するようなものは、プレゼンテーションロジックではなく、ビジネスロジックです。ビジネスレイヤーは必要な単位でデータを返し、適切なラベルを表示するために処理するユニットをプレゼンテーションレイヤーに伝える必要がありますが、それは間違いなくビジネスロジックの問題です。
• Postgresの代わりにOracleを使用しているという事実や、会社がロゴまたはスタイルシートを変更したという事実によって、ビジネスロジックが影響を受けることはありません。
• アプリを作成して自動化するかどうかにかかわらず、ビジネスルールが存在します。ビジネスでペンや紙のようなローテクなソリューションを使用している場合でも、それらを実施できます。
• デスクトップアプリのモバイルバージョンまたはWebバージョンを使用している場合、それらの各バージョンには異なるプレゼンテーションレイヤーがありますが、（できれば）同じビジネスレイヤーがあります。

ほとんどの作業がUIレイヤーで行われているようです。ビジネス上の理由で表示形式を変更しても、ビジネスロジックは含まれません。変更は、ビューロジックの変更です。

フォーマットを変更できるということは、おそらく設定の永続性を伴うビジネスロジックを意味します。

Cookieへの形式の永続化は、ビューレイヤーでも実装できます。

ただし、これはMVC方式で実装できます。（一部のモデルでは、設定を処理できる独自のMVCとしてビューを実装しています。）

• ユーザーの設定は、モデル（データベース/ Cookie）によって保存できます。
• コントローラーは、モデル内のユーザーの設定を変更することにより、フォーマット要求に反応します。
• ビューはユーザーの好みに合わせて調整されます。この設定は、モデルから要求することも、コントローラーから提供することもできます。

アプリケーションに関する知識のある推測を行います。

• 利用可能な債券とそれらの価格設定データを含むモデルがあります。
• 債券の検索、価格の表示、利回りの比較、注文の取得、リクエストへの応答でビジネスモデルから返された結果の表示など、ユーザーができるさまざまなことを確認できるビューがあります。

• ビジネスロジックは次のようなものを処理します。

  • 検索を実行し、表示するビューを提供します。
  • 債券の価格を検索し、表示するビューを提供します。
  • 収率を比較し、表示するビューのデータを提供します。
  • 注文を処理し、モデルに保存します。

これが正しく行われれば、モデルやビジネスロジックを変更せずに複数のビューコンポーネントを提供できるはずです。たとえば、現在のデザインがWebサイトの場合、iPhoneまたはAndroidアプリケーションの新しいビューサーバーは、既存のモデルとビジネスロジックを使用します。これらは、注文が履行されたときにプッシュ通知を提供する新しいビジネス機能を導入する場合があり、複数のレイヤーへの変更が必要になる場合があります。

この内訳により、懸念の分離が可能になります。

• モデルによって表されるデータ層は、比較的安定している傾向があります。
• ビジネスレイヤーは、ビジネス上の意思決定が適用される場所です。要求は満たされますか？必要なデータはすべて取得されていますか？ユーザーは許可されていますか？トランザクションに危険信号はありますか？
• ビューレイヤーは不安定になる傾向があり、複数存在する場合があります。これは、アプリケーションのルックアンドフィールが存在する場所です。他のレイヤーを変更せずに、アプリケーションのスキンを完全に変更することができます。