「すべてのサードパーティ以外のコード」ではないとしても、「ビジネスロジック」は実際にはどういう意味ですか？
仕事やオンラインでビジネスロジックについて多くの人が話しているのを聞いたことがありますが、このサイトでそれについていくつかの質問を読んだことがありますが、この用語はまだあまり意味がありません。たとえば、私がよく目にするいくつかの（言い換えた）ステートメントは次のとおりです。
「ビジネスロジックは、実際のビジネスルールをエンコードするプログラムの一部です。」私が読んだほとんどの定義はこのような循環的なものです。
「ビジネスロジックは、特定のアプリケーションに固有のすべてのものです。」これが「特定のアプリケーションがビジネスロジックにすぎない」とどのように異なるのかはわかりませんが、既存のサードパーティソフトウェアを使用していたはずの一連のホイールを誤って再発明した場合を除きます。したがって、質問のタイトル。
「データアクセスレイヤーの上、GUIレイヤーの下にビジネスロジックレイヤーがあるはずです。」私が書くコードでは、データベースアクセサーはアクセスするデータを認識している必要があり、UIコードはデータを正しく表示するために何を表示しているのかを多く知っている必要があり、その間に実際に行うことはありません。クライアントとサーバーの間でデータのblobを渡す以外の2つの場所。では、実際にビジネスロジックレイヤーに入るのは何でしょうか。
「ビジネスロジックはプレゼンテーションロジックから分離する必要があります。」私たちが得る機能要求のほとんどは、ビジネス上の理由からプレゼンテーションロジックを変更することです。ビジネスルールの1つがデフォルトで米国国債の価格を32の表記法で表示することである場合（ユーザーがそれを構成するためのUIも提供する）、プレゼンテーションロジックは、完全に実装しない場合でも、少なくともこのルールが存在することを知っている必要があります。また、UXデザインの主要な部分は、ソフトウェアが実装しようとしているビジネスルールをユーザーが理解するのに役立つようです。
私が実際にビジネスロジックのみを行うチームに所属していて、ビジネスロジック以外のすべてのロジックが他のチームによって実行されている可能性はありますか？それとも、「ビジネスロジック」の全体の概念が、特定のアプリケーションまたはアーキテクチャでのみ機能する別個のエンティティとして機能するのでしょうか。
答えを具体的にするために、DominoのPizzaアプリを再実装する必要があるとしましょう。ビジネスロジックとは何ですか？そのアプリの非ビジネスロジックは何ですか？そして、ピザの注文に関するビジネスロジックを、ピザの情報のほとんどをデータアクセスレイヤーやプレゼンテーションレイヤーに流すことなく、独自のコードの「レイヤー」に配置するにはどうすればよいでしょうか。
更新：私のチームはおそらく90％のUIコードを実行しており、ビジネスロジックと呼ばれるもののほとんど（すべてではありません）が他のチームまたは会社からのものであるという結論に達しました。基本的に、このアプリケーションはモニタリング財務データ用であり、ほとんどすべての機能は、ユーザーが表示するデータと表示方法をカスタマイズする方法です。売買は行われていませんが（それを行う当社の他のアプリと少し統合していますが）、実際のデータは外部ソースの負荷によって提供されます。ただし、ユーザーが自分の「モニター」のコピーを他のユーザーに送信するなどの操作を許可しているため、これを処理する方法の詳細はおそらくビジネスロジックと見なされます。実際に現在バックエンドコードの一部と通信するモバイルアプリがあり、理想的な世界（基本的には準MVCのM）でUIと共有したいフロントエンドコードの部分を正確に知っているので、それが私たちのBLLだと思います。
User61852の回答は、「ビジネスロジック」が何を参照し、何を参照していないかをより具体的に理解してくれたので、受け入れています。
[〜＃〜] crud [〜＃〜] アプリケーションに関するいくつかのヒントを紹介します。これは、ゲームやグラフィックを多用するアプリの経験があまりないためです。
- ビジネスロジックには通常、ビジネスの所有者が学習したルールが含まれます、または次の例のように、何年にもわたって操作が決定されます： "rejectクライアントが最後の支払いをまだ完了していない場合の新しいクレジット "、または"午前11時以降、朝食は販売しません "、または "月曜日と火曜日、顧客は1つの価格で2つのピザを購入できます"。
- もちろん、プレゼンテーション層は割引の利用可能性、またはクレジットが拒否された理由を示すメッセージを表示する必要がありますが、そのような層はそれらのことを決定するのではなく、内部で起こった何かをユーザーに伝えるだけです。
- 通常、ビジネスロジックにはワークフローが含まれます例： "このアイテムは、3営業日以内にマネージャーまたはプットによって承認される必要があります「情報の要求」段階に進み、お客様が必要な書類を提出していない場合、アイテムは拒否されます "。
- プレゼンテーション層は通常、そのようなワークフローを処理せず、ワークフローの状態を反映するだけです。
- また、データアクセスレイヤーは、ビジネスロジックによって既に決定が行われているため、通常は単純です。このレイヤーは、たとえば、MS SQL ServerからOracleにデータを移行する場合に影響を受けます。
- サーバーへの呼び出しを回避するためにGUIが検証を行うこともありますが、これは慎重に行う必要があります。そうしないと、その層に多くのビジネスロジックを含めることができます。
- 混乱の多くは、アプリケーションには問題の分離がなく、プレゼンテーション層にビジネスロジックが多すぎるという事実から生じた可能性があります。 あなたが（間違って）アプリケーション層またはデータアクセス層にビジネスロジックを持っているという事実は、それがビジネスロジックであるという事実をまったく変更しません。
- マイル/ヤード/フィートの代わりにメートル法で距離を表示するようなものはプレゼンテーションロジックではなく、ビジネスロジックです。ビジネスレイヤーは必要なユニットでデータを返し、適切なラベルを表示するために処理するユニットをプレゼンテーションレイヤーに通知する必要がありますが、これは間違いなくビジネスロジックの問題です。
- ビジネスロジックは、Postgresの代わりにOracleを現在使用しているという事実、または会社がロゴやスタイルシートを変更したという事実の影響を受けません。 。
- ビジネスルールは、アプリを作成して自動化するかどうかに関係なく存在します。企業がペンや紙などのローテクソリューションを使用している場合でも、これらを適用できます。
- デスクトップアプリのモバイルバージョンまたはWebバージョンを使用している場合、それらのバージョンのそれぞれに異なるプレゼンテーションがありますレイヤー、しかし（うまくいけば）同じビジネスレイヤー。
ほとんどの作業はUIレイヤーで行われているようです。ビジネス上の理由で表示形式を変更しても、ビジネスロジックは含まれません。変更はビューロジックの変更です。
フォーマットを変更できるということは、いくつかのビジネスロジックがおそらく設定の永続化を伴うことを意味します。
Cookieへの形式の永続化は、ビューレイヤーにも実装できます。
ただし、これはMVC方式で実装できます。 （一部のモデルは、好みを処理できる独自のMVCとしてビューを実装します。）
- ユーザーの設定はモデル（データベース/ Cookie）に保存できます。
- コントローラは、モデル内のユーザーの設定を変更することにより、フォーマット要求に反応します。
- ビューはユーザーの好みに合わせて調整されます。設定はモデルから要求するか、コントローラーから提供できます。
アプリケーションについて知識のある推測を行う。
- 利用可能な債券とそれらの価格データを含むモデルがあります。
- 債券の検索、価格の表示、利回りの比較、注文の取得、要求に応じてビジネスモデルから返された結果の表示など、ユーザーが実行できるさまざまなことを確認できるビューがあります。
ビジネスロジックは次のような処理を行います。
- 検索を実行し、表示するビューを提供します。
- 債券の価格を検索し、表示するビューを提供します。
- 歩留まりを比較し、ビューに表示するデータを提供します。
- 注文を処理してモデルに保存する。
これが正しく行われれば、モデルやビジネスロジックを変更せずに複数のビューコンポーネントを提供できるはずです。たとえば、現在のデザインがWebサイトの場合、iPhoneまたはAndroidアプリケーションの新しいビューサーバーは既存のモデルとビジネスロジックを使用します。これらは新しいビジネス機能を導入してプッシュ通知を提供する場合があります複数のレイヤーへの変更が必要な場合がある注文の履行。
この内訳により、懸念の分離が可能になります。
- モデルによって表されるデータレイヤーは比較的安定している傾向があります。
- ビジネス層は、ビジネス上の決定が適用される場所です。要求は満たされますか？必要なデータはすべて取得されていますか？ユーザーは承認されていますか？トランザクションに赤信号はありますか？
- ビュー層は安定性が低くなる傾向があり、複数存在する場合があります。これは、アプリケーションのルックアンドフィールが存在する場所です。他のレイヤーを変更することなく、アプリケーションのスキンを完全に変更できます。