ビジネスロジックとアプリケーションロジックの違いは何ですか？[閉まっている]

私がstackoverflowについて同じ質問をしたが、彼らはここで尋ねるように指示したことに注意してください。

アプリケーションロジックとビジネスロジックの違いを識別しようとしていますが、一連の記事を見つけましたが、残念ながらそれらには矛盾があります。

ここ では彼らは同じであると言いますが、ここでの答えはまったく異なります。

私には次のように理解しています。

LogicGoogleで単語の定義を調べると、

特定のタスクを実行するためのコンピューターまたは電子デバイスの要素の配置の基礎となるシステムまたは一連の原則。

したがって、ロジックがその場合、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、それらは同じこと、つまり、プログラムに実行させたいことを実行するプログラムコードの「中間層」の異なる用語です。ソフトウェアの多くのことのように、システムを構築するための単一の正式な定義がないため、システムの各部分に厳密で高速な用語はありません。

そのため、ビジネスロジックと呼ばれることもあれば、アプリケーションロジックと呼ばれることもあれば、プログラムロジックと呼ばれることもあります。これを厳密に定義しようとしないでください。ほとんどすべてのシステムは、その構築方法が異なりますので、用語にこのマイナーレベルのあいまいさしかないことを嬉しく思います。