アプリケーションやプレゼンテーションロジックとは対照的に、ビジネスルールを定義するものは何ですか？
私が自分自身に説明する方法は、ビジネスルールはアプリケーションのドメイン概念の要件であるということです。
現在のアプリのコアタスクの1つは、通知を送信することです。したがって、私にはNotificationエンティティがあります。
APIサービスプロバイダーにはメッセージの長さの制限があるため、メッセージを2つの部分に分割してバッチ送信する必要があるという状況に直面しています。
私の観点からは、これはビジネスルール（要件はアプリの所有者から直接送信されます）、アプリケーションロジック（メッセージが長すぎて現在のAPI実装で一度に送信できない）、またはプレゼンテーション層（メール本文はテンプレートから作成されます）。
このようなルールがどのレイヤーに属するかをどのように識別できますか？
ビジネスルールはビジネスマンによって定義され、これらのルールの実装方法に関係なく、ビジネスの問題に関連しています。
明確な例：
- 受取人の銀行口座の変更は、変更を登録した会計士とは別の会計士によって承認される必要があります（4つの目の原則）。
- 購買担当者は、最大10万ドルの発注書を発行できます。この上限を超えると、マネージャーによる承認が必要になります。
これらのルールは、純粋に組織的な手段（従業員が従うために与えた正式な手順）または自動化（システム内）によって実施できます。
あいまいな例：
- レポートのタイトルは140文字未満にする必要があります
- 製品の説明は2000文字以内でなければなりません
これらの2つの例は次のとおりです。
- ビジネスルールによって正当化されないが、それが十分であると想定されるという理由だけで、任意の長さの技術仕様。
- 真のビジネスルール、たとえば、簡潔な回答と効率的な処理を確実にするために（そして店員が短い小説ではなく長い小説を読まなければならないことを避けるために）ビジネス上の理由でいかなる状況でも情報がこれらの制限を超えてはならないとビジネスマンが決定した場合ステートメント）。
それがビジネスルールであるかどうかを判断するための最も簡単な基準は、このルールがシステムなしで意味をなすかどうかを尋ねることです（たとえば、情報が紙のフォームを介して処理されるかどうか）。あなたの例では、明らかにそうではありません。
ビジネスルールは、その一般的な性質（アプリケーションに依存しない）のため、一般にビジネスロジック層に実装されます。
ビジネスルールとアプリケーションロジックの間には十分な灰色の領域と重複がありますが、ビジネスルールであるためには、要件はビジネスに価値を生み出す要件でなければなりません。
メッセージを送信し、APIのためにメッセージを2つに分割する必要がある例を考えると、本当のビジネス要件は、アプリが任意の長さのメッセージを送信できる必要があることです。ユーザーがより長いメッセージを送信できなかった場合、アプリの所有者はお金を失う可能性があります。メッセージを複数の部分に分割することは、そのビジネスルールの実装になります。
それはビジネスルールではないでしょう。
ビジネスルールを収集し、理想的にはソースコードで参照する必要があります。
すべてのビジネス面に関するロジックを説明する必要があります。請求書を印刷した後は、請求書番号を変更できなくなり、監査ログに記録する必要があります。
これで、ビジネスルールを設定できます。この...イベントに関する通知を送信します。実装コードは、このビジネスルールを参照し、必要に応じて、大きすぎるメッセージを別々に送信される2つの部分に分割することを述べる場合があります。これは、事前の要件ではなく、後の実装ドキュメントのように見えます。 「iをクリックして、状況に応じたオンラインヘルプを受け取ることができます。」のようなものです。
ビジネスルールしかない場合は、実装の詳細を追加します。それ以外の場合は、それらを分離し、ビジネスルールの所有権を中立に保ち、あまり毛羽立たないようにします。ビジネスマンは、課せられた詳細/「修正」によって過度に制限されていると感じるべきではありません。リストのページネーションなどのようなものです。 「結果は限られたページに収まる必要がありますが、スクロール可能なリスト全体も選択可能でなければなりません。」それは-あなたが言ったように-アプリケーション設計のための何かです。そして、-決定的なビジネスルールとは対照的に-は国際的に何かを伝えます。
2つのメッセージがあることを説明する必要があります。しかし、比較してみましょう。
建築家は言う：N人とM階の建物のKエレベーターがあります。建物の所有者は、1階と最上階でインテリジェントなエレベーターがどのように待機するか、ボタンを押したときにどのように対応するかなどの技術文書を用意する必要があります。 重要な技術的実装の詳細、インテリジェントデザインの決定。 2つの通知メッセージの送信は同じカテゴリに分類されます。
ビジネスルールでは、「通知メッセージ」を「1つまたは2つのメッセージとしての通知（脚注：通知が長くなりすぎる場合）」に変更する必要がありますが、技術的な理由と詳細は別の場所に配置する必要があります。
これで、ビジネスルールにあまり影響を与えずに実装を変更できます（これらのルールは、単一の部分的な「メッセージ」ではなく、「通知」を処理します）。