私はPHPを始めた2009年からWeb開発に取り組んでいます。ASP.NETに移行したとき、この「ビジネスロジック」と「ビジネスルール」に多くの焦点が当てられているDDDとOOADについてよく耳にしました。要点は、これまでに開発したアプリはすべてCRUD操作に関するものであり、実際にこれらのことを見たことがないということです。
それらが実際に実際にどのようなものになるのか、私には想像できません。それでは、このビジネスロジックとはどのようなもので、アプリにどのように適合するのでしょうか？私はこれらがドメインモデルのメソッドとして実装されていることを知っていますが、それらのメソッドは何である可能性があり、アプリケーションのどこで使用される可能性がありますか？
回答:
CRUDは、作成、読み取り、更新、削除を表す頭字語です。これらは、データベースタプルで実行できる4つの基本操作です。 しかし、ビジネスアプリケーションには常に、データベースレコードの作成、読み取り、更新、削除以外のこともあります。
いくつかの基本的な定義から始めて、いくつかの例を見て、それらの定義が例にどのようにマッピングされ、実際のソフトウェアにどのようにマッピングされるかを見てみましょう。
ビジネスロジックまたはドメインロジックは、データの作成、保存、変更の方法を決定する実際のビジネスルールをエンコードするプログラムの一部です。ビジネスオブジェクトが相互にどのように相互作用するかを規定し、ビジネスオブジェクトにアクセスして更新するルートとメソッドを実施します。
ビジネスルールは、組織に適用される操作、定義、および制約を記述します。操作は集合的にプロセスを形成します。すべてのビジネスはこれらのプロセスを使用して、物事を成し遂げるシステムを形成します。
それでは、いくつかの例を見てみましょう。
まず、知っておくべきことは何ですか（入力）？
適用する必要がある「ビジネスルール」にはどのようなものがありますか？
「アトミック」とは、トランザクションが完全に成功するか、完全に失敗する必要があることを意味します。他の口座に入金せずにある口座からお金を引き出す（お金が消える）、または口座に入金されたが別の口座から引き落とされない（お金が魔法のようにどこからでも現れる）口座取引はできません。
何を知る必要がありますか？
注文後、どうなりますか？
請求書/発送リストが印刷され、注文とともに配置されます
..等。
CRUDは、アプリケーションが行う作成、読み取り、更新、削除にすぎません。
バグトラッカーもある程度、CRUDアプリです。バグを作成し、バグを読み取り（表示）、バグを更新し、場合によっては削除します。
ただし、バグトラッカーには単なるCRUD以外のものもあります。
上記を実装するコードは、アプリケーションのビジネスロジックです。
ワークフローの制限、または誰 CRUDでさまざまな操作を行うことができます。これらは、CRUDアプリを別のものから分離するものです。これらは、アプリケーションがどのように機能するかをビジネスに実際に伝えるために必要な部分です。それは論理的です...まあ、それはプロジェクトマネージャーの耳からビールについて議論するのが一番です。しかし、それがビジネスロジックです。
もちろん、ロールのない「純粋な」CRUDアプリを作成することは可能です。すべてを変更して表示できますが、これらはルールではなく例外です。
ビジネスロジックは、与えられたビジネスルールを処理するためにプログラムに書き込むロジックです。
ビジネスルールを開始するとき、これはcrud自体またはビジネスロジックよりも高いレベルになる傾向があります。これは、ビジネスで働いているビジネスアナリストから得られるものである傾向があります。
この例では、店舗の返品デスクで商品の返品を処理する方法を決定するプログラムを検討します。
これらはいくつかのビジネスルールです。彼らは、アプリケーションのCRUD部分とは話しません。
ビジネスルールを使用する場合、システムで生のコードを記述する代わりに、ルールエンジン（たとえば、Windows Workflow Foundation Rules Engine）で記述されていることがよくあります。
ロジック/ルールの区別は用語の1つであり、一晩中議論することができることを理解してください（再びビールよりも良い）。これは珍しい違いではありませんが、2つは互いに溶け込むことができます。
他の答えは正しいです。もう1つの考え…
Turbo PascalからJavaに移行するなど、別のプログラミング言語でソフトウェアプロジェクトを再実装する場合、ビジネスロジックとビジネスルールは、古いプロジェクトと新しいプロジェクトの共通点です。
プログラミング言語は異なるだろう。ソースコードは全く異なるだろう。ツール（IDE、コンパイラなど）はまったく異なる場合があります。ユーザーインターフェースは完全に再編成するか、異なる場合がありますルック＆フィールを。ドキュメントは、おそらく違うだろう。しかし、2つのプロジェクトの目的、実行された作業/達成された目標の最終結果は同じです。
ビジネスロジックは基本的に、検証とフローという2つの広範なカテゴリで構成されています。ビジネスロジックによれば、数量1は数量2以上でなければなりません。たとえば、購入するアイテムの数は在庫のアイテムの数以下でなければなりません。
あるアプリケーションでは、ビジネス関係者はこれがビジネスルールであると言うので、このビジネスロジック（検証）を強制するコードを記述します。別のアプリケーションは、注文したアイテムの数が在庫のアイテムの数よりも多い場合、注文を受け入れ、差額に20％を加えた独自の注文を出すと言うので、このビジネスロジック（フロー）を記述します。
CRUDは単にデータをストレージに出し入れするだけで、それを変更します。ビジネスロジックは、そのデータを使用して何をするか、およびそれに対して許可される変換を決定します。あなたの顧客は将来、5歳未満の特定の地理的地域（地元の人/訪問者の割引）から生まれていますか。CRUDは簡単です。子供が6か月以上でなく暦年に半分の時間以上住んでいた場合にのみ子供の税額控除を取得できることを知っているのは、より複雑です。