本当に「ビジネスロジック」とは何ですか？
PHPを始めた2009年から、Web開発に取り組んでいます。 ASP.NETに移動したとき、この「ビジネスロジック」と「ビジネスルール」に重点が置かれているDDDとOOADについてよく耳にしました。ポイントは、これまでに開発したすべてのアプリはすべてCRUD操作に関するものであり、実際にこれらのものを見たことはありません。
私はそれらのものが実際に実際に何であることができるか想像することはできません。では、このビジネスロジックとは何であり、これがアプリにどのように適合するのでしょうか。これらがドメインモデルのメソッドとして実装されていることは知っていますが、それらのメソッドはどのようなものであり、アプリケーションのどこで使用できるのでしょうか。
[〜＃〜] crud [〜＃〜] は、作成、読み取り、更新、および削除を表す頭字語です。これらはデータベースタプル。で実行できる4つの基本的な操作ですが、ビジネスアプリケーションには、データベースレコードの作成、読み取り、更新、および削除以外にも多くの機能があります。
基本的な定義から始めて、いくつかの例を見て、それらの定義が例にどのようにマッピングされるか、および実際のソフトウェアにどのようにマッピングされるかを見てみましょう。
ビジネスロジック またはドメインロジックはプログラムのその部分これは実際のビジネスルールをエンコードしますデータの作成、保存、変更方法を決定します。ビジネスオブジェクトが相互にどのように相互作用するかを規定し、ビジネスオブジェクトにアクセスして更新するためのルートとメソッドを適用します。
ビジネスルール 組織に適用される操作、定義、および制約について説明します。操作はまとめてプロセス;を形成します。すべてのビジネスはこれらのプロセスを使用して、物事を成し遂げるシステムを形成します。
それでは、いくつかの例を見てみましょう。
ある当座預金から別の当座預金への送金
まず、知っておくべきこと（入力）は何ですか？
- 転送を行う人の身元
- 振込金額
- ソース当座預金口座番号
- ターゲット当座預金口座番号
適用する必要がある「ビジネスルール」にはどのようなものがありますか？
- リクエストを行う人は、そうする権限を持っている必要があります。
- トランザクションは atomic でなければなりません。
- 取引が一定額を超える場合、政府への報告要件がある場合があります
「アトミック」とは、トランザクションが完全に成功するか、完全に失敗する必要があることを意味します。一方のアカウントからもう一方のアカウントに到着せずにお金が引き落とされる（お金が消える）、または別のアカウントから引き落とされない（お金がどこからでも魔法のように見える）場合は、アカウントトランザクションを実行できません。
アマゾンから何かを注文する。
あなたは何を知る必要がありますか？
- 注文者の身元
- 出荷情報
- 課金情報
- 支払方法
- 発送する各アイテムの量と数量
- 発送方法（夜間、スローボート、スーパーセーバー）
- 州税率
注文後はどうなりますか？
- アイテムは在庫からプルされます
- 手持ちの数量が借方記入されます
- アイテムは出荷用にパッケージ化されています
- 在庫切れの商品は入荷待ちです
- 最小数量を下回るアイテムが注文されました
- 1回の発送か2回の発送か？
請求書/配送リストが印刷され、注文とともに配置されます
..等。
CRUDは、単にアプリケーションが行う作成、読み取り、更新、削除です。
ある程度、バグトラッカーもCRUDアプリです。バグを作成し、バグを読み取り（表示）、バグを更新し、場合によっては削除します。
ただし、バグトラッカーにはCRUDだけではありません。
- 開発者はバグを検証済みまたはクローズ済みとしてマークすることはできません。これはQAの仕事の一部です。そのため、QAの役割を持たない誰かがバグをクローズまたは検証済みとしてマークできないようにするためのコードがいくつかあります。
- プロジェクトマネージャー以外は実際にバグを削除できません。
- バグに「私をテストする」というマークを付けるには、バグに対するコードのコミットが少なくとも1つ必要です。
- 「クローズ」状態のバグのみが「再オープン」状態に移行できます
- バグに割り当てられた開発者は、「コードレビュー」から「コードレビュー完了」に移動できません
- QAと開発者は、割り当てられているプロジェクトのバグのみを表示できます。
上記を実装するコードは、アプリケーションのビジネスロジックです。
ワークフローの制限、またはwhoはCRUDでさまざまな操作を実行できます。これらは、CRUDアプリを別のアプリから分離するものです。これらは、ビジネスに実際にアプリケーションを機能させる方法と言わせるために必要な部分です。それがいかに論理的であるか...まあ、それはプロジェクトマネージャーの耳からのビールについて最もよく議論されます。しかし、それがビジネスロジックです。
もちろん、役割のない「純粋な」CRUDアプリを作成することは可能であり、すべてを変更して表示することができますが、これらは規則ではなく例外です。
ビジネスlogicは、与えられたビジネスルールを処理するためにプログラムに書き込むロジックです。
ビジネスルールに取り掛かると、これは、クラッド自体やビジネスロジックよりも高いレベルになる傾向があります。これは、ビジネスで働いているビジネスアナリストから得られるものです。
この例で、店舗の返品デスクでのアイテムの返品を処理する方法を決定するプログラムについて考えます。
- 領収書が90日以上前のものである場合、店内クレジットのみが付与されます
- レシートが90日以内の場合、レシートが購入に使用された入札にクレジットを付けます（クレジットはクレジットカードに戻り、現金は現金に戻り、店内クレジットは店内クレジットに戻ります）...それ以外の場合小切手でした。この場合、現金を使用してください。
それらはいくつかのビジネスルールです。アプリケーションのCRUD部分については話しません。
ビジネスルールを使用する場合、システムで生のコードを記述する代わりに、 ルールエンジン （たとえば Windows Workflow Foundationルールエンジン ）で記述されることがよくあります。
ロジック/ルールの区別は用語の1つであり、一晩中論じることができる（ビールよりも良い）ことを理解してください。これは珍しい違いではありませんが、2つは互いに融合することができます。
他の答えは正しいです。もう1つの考え…
ビジネスロジックは移植可能
別のプログラミング言語で ソフトウェアプロジェクトを再実装 した場合、たとえば Turbo Pascal から Java 、ビジネスロジック ＆ ビジネスルール は、古いプロジェクトと新しいプロジェクトに共通するものです。
プログラミング言語 は異なります。 ソースコード は完全に異なります。ツール（ [〜＃〜] ide [〜＃〜] s、 compilers など）は完全に異なる場合があります。 ユーザーインターフェイス は完全に再編成されるか、別の look-and-feel になる場合があります。 documentation はおそらく異なるでしょう。しかし、2つのプロジェクトの目的、実行された作業の最終結果、達成された目標は同じになります。
ビジネスロジックは基本的に、検証とフローの2つの大きなカテゴリで構成されます。ビジネスロジックによると、数量1は数量2以上である必要があります。たとえば、購入するアイテムの数は在庫アイテムの数以下である必要があります。
1つのアプリケーションでは、ビジネススタッフはこれがビジネスルールであると言うので、このビジネスロジック（検証）を適用するコードを記述します。別のアプリケーションは、注文されたアイテムの数が在庫のアイテムの数よりも多い場合、注文を受け入れて、差に20％を加えた独自の注文を行うと言うので、このビジネスロジック（フロー）を記述します。
CRUDは、単にストレージのデータを取得および変更し、それを変更するだけです。ビジネスロジックは、そのデータをどのように処理するか、およびそのデータに対して実行できる変換を決定します。あなたの顧客は将来、5歳未満で特定の地域から生まれましたか（地元の人/訪問者の割引）。 CRUDは簡単で、子供が6か月以上ではなく、暦年に生きていた時間の半分以上を一緒に住んでいた場合にのみ子供税額控除を受けることができることを知っていれば、さらに複雑になります。
ビジネスロジックまたはルールはしないでくださいはユーザーインターフェイスのメカニズム（「プログラミング」）に関係するものです。これらは、このトランザクションまたは100年前に（手動で）何を行っていたとしても、まだ適用する必要があるものです。たとえば、購入に消費税をいつ適用するか。
プログラムまたはアプリケーションの「ビジネスロジック」は、実際に（ユーザー、オペレーティングシステムなどからの）入力を使って処理を行うコードの一部です。アプリケーションの「ビジネスルール」は通常、プログラム自体の定義されたパラメーター（入力の処理方法など）です。少なくとも、これは多くの人々からそれが言及されたと聞いた方法です。これらは、コードの一部を説明するのによく似た用語です。