DDD - ビジネス上の決定はデータベースロジックに基づいています

Question

次のパターンでDDDを実行しようとしています。

Controller-----DataContract----> Domain Layer (DDD) 

Controller-----Domain Object---> Repository---Entity--->EntityFramework 

あなたは上の図でわかるように、ドメイン層は、ビジネス上の意思決定を行うためには無関係ですが、私の場合には、ビジネス上の意思決定のほとんどは、その場で撮影されています。あなたは上記の例を見るとわかるように、例えば

if(Account Number Associated?) 
    Load CustomerDetails //A database call is needed 
    .... 
    ..... 
    if(Has customer another loan) 
      ..... 
      ..... 
      Load other loan details //A database call is needed 
      ..... 
      ..... 
      if(Was that repaid?) 
       .... 
       .... 
       Load collateral details //A database call is needed 
       ..... 
       ..... 
       Calculate collateral details and return. 
      else 
       Load other data //A database call is needed 
     else 
      Load other data //A database call is needed 

else 
    Load other data //A database call is needed 

は、アプリケーションがデータベース呼び出しを行うことにより、その場でビジネス上の意思決定の多くを行うことです。 ドメイン・レイヤーは、リポジトリ・レイヤーに依存してはいけません。続行する方法はわかりません。

私は、データベース・コールのためのアプリケーションサービスを使用することができますが、その後ドメイン・レイヤーはそれで任意のロジックを持っていないでしょう。すべてのロジックはアプリケーションサービスに入っています。

私を助けてください。

-Pandian

Answer 1

一度集合体全体をロードするためのリポジトリを設計

1）うち、少なくとも3つの方法があります。このアプローチは、オンデマンドで状態をロードしようとするのではなく、すぐに必要となる可能性のある状態をすべてドメインモデルに与えます。

2）アプリケーションサービスでクエリを実行し、そのデータをドメインモデルに渡します。理想的には、事前にこれを行い（ドメインモデルを1回呼び出す）、それが意味をなさない場合、ドメインモデルでアプリケーションサービスに必要なデータを伝え、アプリケーションサービスがそれを検出するようにしますデータを返し、それを返します。

3）リポジトリを必要なデータを読み取ることができるドメインモデルに渡します。これは本質的に「ドメインサービス」パターンですが、データストアにアクセスするために使用されます。

この設計では、ドメインモデルはリポジトリインタフェースを定義しており、アプリケーションはその実装を提供しています。つまり、サービスプロバイダのパターンを使用して、依存関係の矢印が正しい方向を向いているようにします。

Answer 2

@Pandiarajanドメインレイヤには、ドメインモデル（エンティティ、値オブジェクト）、ドメインサービス、ドメインイベントを含めることができます。

上記のコードから、値オブジェクトまたはエンティティとして自然にモデル化されていないこれらのドメインロジックと概念をすべてカプセル化するドメインサービスを作成できます。これらのドメインサービスは、すべてのデータベース呼び出しを処理するリポジトリをとることができます。

返す必要があるデータが読み取り専用またはレポート目的の場合は、代わりにCQRSを探すこともできます。 CQRSでは、これらの読み取りクエリはすべて、データを提示する際にドメインレイヤをバイパスできます。 CQRSはデータをドメインモデルに変換する必要性を排除します。