ビジネスロジックとアプリケーションロジックの違いは何ですか？
stackoverflow についても同じ質問をしましたが、ここで質問するよう指示されたことに注意してください。
アプリケーションロジックとビジネスロジックの違いを識別しようとしていますが、一連の記事を見つけましたが、残念ながらそれらには矛盾があります。
ここ 彼らは同じであると言いますが、答え ここ はまったく異なります。
私には次のように理解しています。
GoogleでLogic Wordの定義を検索すると、次のようになります。
特定のタスクを実行するための、コンピューターまたは電子デバイス内の要素の配置の基礎となるシステムまたは一連の原則。
したがって、ロジックがset of principles underlying the arrangements of elementsその場合、ビジネスロジックはset of principles underlying the arrangements of the business rules、つまり、システムを取得するために従うべきルールがビジネスニーズを反映していることを意味します。
そして、私にとってのアプリケーションロジックはthe principles that the application based on、つまり、これらのルールを適用してシステムを取得する方法は、ビジネスニーズを反映します。たとえば、MVCを使用すべきか、使用すべきでないか、SQLやMSSQlを使用すべきかなどです。
ですから、アプリケーションとビジネスロジックの違いに関する混乱を取り除くために誰かが私を助けていただけませんか。
私はSOのLoztInSpaceに同意します。これはかなり独断的な答えであり、誰もがわずかに異なる定義を持つことができるということです。特に歴史的な影響が含まれている場合。これは私が用語を定義する方法です：
ビジネスロジックは、ビジネスエキスパートとのコラボレーションと合意によって作成されたロジックです。ビジネスの専門家が「顧客は自分の口座に持っている以上の金額を引き出すことはできない」と言った場合、これはビジネスルールです。理想的には、このロジックはある種のライブラリまたはサービスに含まれるため、複数のアプリケーションで再利用するか、すべての関連アプリケーションで一度に変更できます。
アプリケーションロジックは、他のすべてのものです。たとえば、「このボタンをクリックするとウィンドウが開き、新しい顧客を追加できます」のようになります。ビジネスとは何の関係もありませんが、実装する必要のあるロジックです。理想的な世界では、アプリケーションロジックは、ビジネスルールを実装するライブラリまたはサービスを使用します。それぞれが異なるアプリケーションロジックを持つ複数のアプリケーションは、1つのビジネスロジックを再利用できます。 Webアプリ、Webサービス、モバイルアプリはすべて1つのビジネスロジックを使用して動作しているが、それぞれに異なるアプリケーションロジックが必要であることを想像してください。
私がこれら2つが混同すると思う理由は、それらを別々に保つことは非常に難しいためです。それらを別々に保つために最善を尽くしても、それらを混ぜる必要があるユースケースが浮上します。たとえば、すべてのビジネスロジックが稼働している場合、それを分離します。ただし、サービスを使用しているローカルアプリケーションにビジネスロジックがあると、ローカルアプリケーションは小さな変更ごとにサービスを呼び出す必要がないため、応答性やユーザーの快適性が向上します。
それらが一緒に混合されるもう1つの理由は、多くの非技術者のためです。 UIは「アプリケーション」であるため、UIに反映されているものはすべて重要です。理想的な「ビジネスロジック」の場合、UIはありません。おそらく、ロジックを検証するための一連の自動テストがありますが、ビジネスの人々に見せることはできません。ビジネスマンにとって、すべては同じ種類の「論理」です。 IMO。
他の人が指摘したように、これらの用語には、広く受け入れられている1つの意味はありません。私がより頻繁に、つまり異なる会社とのいくつかのプロジェクトで遭遇した定義について説明します。
ビジネスロジックは、アプリケーションが記述されているビジネスドメインの正規化された汎用モデルを定義します。
Customer、Order、OrderLineなどのクラス、およびcustomer-orderなどの関連付けなど。registerCustomer、cancelOrderなどの汎用操作
多くの場合、このクラスモデルはデータベースモデルにマッピングされ、マッピングはORMを使用して実装されます。通常、操作はそれぞれ独自のトランザクションで実行され、データベースを変更するための基本的なAPI、つまりアプリケーションの永続的な状態を提供します。
アプリケーションロジックは、ビジネスロジックの上に構築されたレイヤーであり、特定のユースケースを実装するのに役立ちます。アプリケーションロジックモジュールは、アドホックデータ表現を使用できます。顧客のみを一覧表示する場合は、Orderに関連付けられていないCustomerSummaryクラス。このようなアドホックデータ表現は、ビジネスモデルによって提供される基になる正規化表現にマップする必要があります。たとえば、CustomerSummaryはCustomerの上のビューとして定義できます。
2つのレイヤー間の境界が明確に定義されていない場合があることに注意してください。例えば。いくつかのユースケースを実装した後、アプリケーションロジック内の同様のデータ構造に気づき、それらを統合（正規化）してビジネスロジックに移動することを決定する場合があります。
すべてのシステムまたはアプリケーションは、ビジネスロジックとは何か、アプリケーションロジックとは何かについて独自の定義を持ちます。明示的または暗黙的です。
私の経験では、データ駆動型アプリケーション（DBなど）は、ビジネスロジックが何であるかをより正式に定義する傾向があります。
アプリケーションロジックはポイントAからポイントBへの情報の取得に重点を置く傾向があり、ビジネスロジックは情報が何であるかを中心としています。ビジネスロジックの言語は通常、ドメイン固有です。言い換えれば、アプリケーションロジックは「それはどのように機能するのか」という質問に焦点を当てており、ビジネスロジックは「それは何をするのか」に焦点を当てています。 -繰り返しになりますが、この区別は非常にあいまいで、多くの場合、ドメイン固有ではありません。
Na、それらは同じこと、つまりプログラムに実行させたいことを実行するプログラムコードの「中間層」の異なる用語です。ソフトウェアの多くのことと同様に、システムを構築するための単一の正式な定義がないため、システムの各部分に厳密で高速な用語はありません。
そのため、ビジネスロジックと呼ばれることもあれば、アプリケーションロジックと呼ばれることもあれば、プログラムロジックと呼ばれることもあります。これをそれほど厳格に定義しようとしないでください。ほとんどすべてのシステムは、その構築方法が異なるので、用語にこのマイナーレベルのあいまいさが存在するだけで嬉しいです。