0

私は、ドメイン駆動設計をますます理解し、ベスト プラクティスに従うようにしています。これまでのところ、これは私の理解です：

  • 集約は、相互に関連するエンティティのコレクションです。
  • 集約のルートは、集約の関係を結び付けるエンティティーです。
  • ルートが削除された場合、集約の範囲内にあるものもすべて削除する必要があります
  • 集約ルートは ID を介してのみ相互に参照できます

私の質問は次のとおりです。

相互に関連する集計が複数ある場合は、注文と製品カテゴリとします。

アプリケーション サービスは、注文と関連する製品カテゴリの取得をどのように処理する必要がありますか?

サービスは、注文と製品カテゴリの各リポジトリへの参照を持つ必要があります。最初に注文を取得し、次に製品カテゴリを取得し、最後に両方からの情報を参照するデータ転送オブジェクトを入力しますか?

このようなもの：

public OrderDto GetOrder(int id)
{
    var order = _orderRepo.GetById(id);

    var productCategory = _categoryRepo.GetById(order.ProductCategoryId);

    return new OrderDto 
                  { 
                     CustomerName = order.CustomerName, 
                     ProductCategoryName = productCategory.Name,
                     *..etc..*
                  };
}

それとも、密接に関連している場合、切り離されたルーツを維持するのはオーバーキルですか？

それとも、全体像を把握するために、UI は独立したサービスを呼び出す必要がありますか?

4

2 に答える 2

1

「ルールを破る理由」セクションに従って、ルールを破らなければならない状況がいくつかあります。

それらの最初のものは事前設定の便利さです。一度に 1 つの Order を表示する必要がある場合は大したことではありませんが、 Order をリストする必要がある場合、言及した解決策は N + 1 クエリの問題を引き起こします。

別の解決策は、ルールに固執し、永続化インフラストラクチャからドメイン モデルを分離する (または既に分離している) 場合は、永続化オブジェクトを使用して ui (リストの順序の場合) をレンダリングすることです。

于 2013-08-28T00:58:55.317 に答える