Order エンティティのドメイン層で検証するビジネス ルールがあります。ルールは、顧客が特定の割引を受ける資格を得るには、少なくとも 30 日間ストアでアカウントを持っている必要があるというものです。値 30 は、ドメイン層の Order Entity で定数として定義することも、ストアド プロシージャの一部として定義することもできます。この場合、定数として定義され、アプリケーション サービスによって呼び出されたときに返され、ルール検証のために Domain Entity に渡されますか?
ストアド プロシージャ内にある場合は、データベース内の番号を変更し、ストアド プロシージャを再コンパイルできます。これは、他のユーザーにほとんど関与せずに非常に簡単に行うことができます。しかし、エンティティに入れると、再コンパイルだけでなく再配布が必要なアプリケーション コードの一部になります。
DDD 設計を実装しようとしている N 層設計アプリケーションのために、これらの種類の数値定数はどこに保存されていますか?
簡単な答え: ドメインに属しています:)
そうですね、リポジトリを定義するのと同じ方法でドメインに定義されたインターフェースです。実装はどこでもかまいませんし、ドメインに含まれるデフォルトの実装を含めることさえできます。
あなたの例では、割引条件はかなり単純です。ただし、割引率の決定がより複雑なシナリオについてはどうでしょうか? テストがより困難になるため、ストアドプロシージャではそれを望まないでしょう。ストアドプロシージャに配置すると仮定しましょう。プログラムを使用している複数のクライアントがそれぞれ異なる日数を必要とする場合はどうなりますか。
要点は、ドメインの専門家とともに、必要に応じて柔軟にルールを構成および設計する方法を決定する必要があるということです。たとえば、日を変更するだけでよい場合は、システムで構成可能な設定としてそれを使用できます。
ただし、おそらく戦略パターンに従うものが必要です。考えてみれば、ほとんどのシステムは戦略パターンです:)
とにかく、次のこと（またはあなたのシナリオで意味のあるもの）はどうですか：
public interface IDiscountService
{
float GetDiscount(Customer customer, Order order);
}
実装IDiscountConfigurationでは、日数を取得する必要がある場所 (app.config、web サービス、xml、データベース) に日数を提供する注入を行うことができます。
このメカニズムを使用すると、特定の実装に依存することなく、任意の時点で割引を決定する方法を変更できます。クライアントごとに異なる実装を行い、現在の環境に関連する割引計算機を単純にインスタンス化することもできます。
newまた、単体テストでインスタンスを起動してテストを実行すると、さまざまなサービスのテストが簡単になります。