アプリケーションの「ビジネス ロジック」とは正確には何で構成されているのでしょうか?

Question

「ビジネス ロジックと他のコードを混ぜるべきではない」、またはそのような発言を何度も聞いてきました。私が書くすべてのコード (つまり、処理ステップ) は、ビジネス要件に関連するロジックで構成されていると思います。

ビジネス ロジックの正確な構成を誰か教えてください。他のコードとどうやって区別できるのでしょうか？何がビジネスロジックで何がそうでないかを判断するための簡単なテストはありますか?

Answer 1

自分が何をしているのかを簡単な英語で定義するだけです。「あの人たちを苦しめる」「そのお金を盗む」「地球のこの部分を破壊する」など、ビジネス的なことを言っているとき、それはビジネス層のことを話していることになります。はっきり言っておきますが、あなたが興奮するものはここにあります。

「ここにこれを表示する」、「あれは表示しない」、「もっと美しくする」と言っているとき、それはプレゼンテーション層について話していることになります。これらはデザイナーを興奮させるものです。

「これを保存する」、「データベースからこれを取得する」、「更新する」、「削除する」などのことを言うとき。あなたはデータ層について話しているのです。これらは、どんな犠牲を払ってでも永遠に保持しておくべきものを教えてくれます。

Answer 2

何から始めた方が簡単かもしれません そうではありません ビジネスの論理。データベースやディスクへのアクセスはビジネス ロジックではありません。UIはビジネスロジックではありません。ネットワーク通信はビジネス ロジックではありません。

私にとって、ビジネス ロジックとは、ソフトウェア アーキテクチャがどのように動作するかではなく、ビジネスがどのように動作するかを説明するルールです。ビジネスロジックも変化する傾向があります。たとえば、すべての顧客が自分のアカウントに関連付けられた 1 枚のクレジット カードを持っていることがビジネス要件になる場合があります。この要件は、顧客が複数のクレジット カードを持てるように変更される可能性があります。理論的には、これはビジネス ロジックへの変更だけであり、ソフトウェアの他の部分は影響を受けません。

それが理論です。現実の世界では (お気づきのように) ビジネス ロジックはソフトウェア全体に広がる傾向があります。上記の例では、追加のクレジット カード データを保持するために、データベースに別のテーブルを追加する必要がある可能性があります。必ず UI を変更する必要があります。

純粋主義者は、ビジネス ロジックは常に完全に分離されるべきであり、データベース内に「Customers」または「Account」という名前のテーブルを置くことさえ反対すると主張します。極端に考えれば、信じられないほど汎用的で保守が不可能なシステムになってしまうでしょう。

ビジネス ロジックのほとんどをシステム全体に散らかすのではなく、まとめて保持することを支持する強力な議論は間違いなくありますが、(ほとんどの理論と同様に) 現実の世界では実用的である必要があります。

Answer 3

ビジネス ロジックとアプリケーション要件を混同しているようです。それは同じではありません。誰かが自分のビジネスのロジックを説明するとき、それは次のようなものです。

「ユーザーは商品を購入する際、配送情報を提供する必要があります。情報は xy z ルールで検証されます。その後、請求書を受け取り、ポイントを獲得すると、y 件のオファーに対して x% の割引が与えられます。」 (悪い例ですみません)

このビジネス ルールを実装するときは、情報の表示方法、永続的な方法での保存方法、アプリケーション サーバーとの通信、ユーザーが請求書を受け取る方法など、二次的な要件を考慮する必要があります。これらすべての要件はビジネス ロジックの一部ではないため、ビジネス ロジックから切り離す必要があります。こうすることで、ビジネス ルールが変更されたときに、少ない労力でコードを適応させることができます。あれは事実です。

プレゼンテーションでは、主にユーザー入力の検証において、ビジネス ロジックの一部が複製される場合があります。ただし、ビジネス ロジック層にも存在する必要があります。他の状況では、パフォーマンスの問題のために、一部のビジネス ロジックをデータベースに移動する必要があります。これについては Martin Fowler が議論しています ここ.

Answer 4

物事を 1 行に単純化するには...
ビジネス ロジックは、特定の UI/実装の詳細に依存しない、または変更されないコードになります。ルールやプロセスなどをコードで表現したものです。モデル化されているビジネスによって定義され、モデル化されているビジネスを反映しています。

Answer 5

私はレイヤーの BLL+DAL 名が好きではありません。明確にするというよりも混乱させるためです。
これを DataServices および DataPersistence と呼びます。これで簡単になります。

サービスは永続層 CRUD (作成、読み取り、更新、削除) を操作します。

Answer 6

私にとって、 " ビジネスの論理 " は、問題ドメインに適用できるデータを表すすべてのエンティティと、「データをどうするか」を決定するロジックを構成します。

したがって、実際には「データ転送」(アクセスではなく) と「データ操作」で構成されるはずです。実際には、データ アクセス (DB にアクセスするもの) は、プレゼンテーション コードと同様に、別のレイヤーにある必要があります。

Answer 7

フォーム、ボタンなどに関するものが含まれている場合。これはビジネス ロジックではなく、プレゼンテーション層です。ファイルまたはデータベースへの永続性が含まれる場合、それは DAL です。その間にあるものはすべてビジネス ロジックです。実際には、UI 以外のものはすべて「ビジネス ロジック」と呼ばれることがありますが、それはハウスキーピングではなく、問題領域に関係するものである必要があります。

Answer 8

ビジネス ロジックは純粋な抽象化であり、ユーザーの目の前にあるデータの具体化/視覚化や、基礎となるデータの永続化とは独立して存在します。

たとえば、Tax Preparation ソフトウェアでは、ビジネス ロジック クラスの役割の 1 つは未払い税の計算です。彼らはレポートを表示したり、納税申告書を保存して取得したりする責任を負いません。

---

@Lars、「サービス」は特定のアーキテクチャを意味します。