19

私は DDD 開発を数日間学んでおり、気に入り始めています。

私（と思う）は、主な焦点がビジネスオブジェクトにあり、集約、集約ルート、集約ルート専用のリポジトリなどがあるDDDの原則を理解しています。

DDD 開発と Code First アプローチを組み合わせた単純なプロジェクトを作成しようとしています。

私の質問は次のとおりです:(私はasp.net MVCを使用しています)

  1. DDD ビジネス オブジェクトは Code First オブジェクトとは異なりますか? それらがおそらく同じであっても、たとえば、Productすべてのルールとメソッドを持つビジネス オブジェクトを持つことができProduct、データベースに保存する必要があるプロパティだけを含むコード ファースト (POCO) オブジェクトを持つことができます。

  2. Product質問 1 の答えが「真」の場合、ビジネス オブジェクトのプロパティProductが変更され、更新する必要があることを POCO オブジェクトに通知するにはどうすればよいですか? 「AutoMapper」などを使用していますか? 答えが「いいえ」の場合、私は完全に迷っています。

これら 2 つを組み合わせる方法の最も単純な (CRUD) 例を教えてください。

ありがとうございました

4

5 に答える 5

7

更新「ドメイン オブジェクト」の使用を推奨するのではなく、メッセージング ベースのドメイン モデルの使用を推奨します。例については、こちらを参照してください。

#1 に対する答えは、場合によるということです。どのエンタープライズ アプリケーションでも、ドメイン内に次の 2 つの主要なカテゴリがあります。

ストレートCRUD

オブジェクトの次の状態はオブジェクトの前の状態に依存しないため、ここではドメイン オブジェクトは必要ありません。それはすべてデータであり、動作ではありません。この場合、どこでも同じクラス (つまり、EF POCO) を使用してもかまいません: 編集、永続化、表示。

この例は、注文に請求先住所を保存することです。

public class BillingAddress {
  public Guid OrderId;
  public string StreetLine1;
  // etc.
}

一方、私たちは...

ステートマシン

ドメインの動作と状態の永続性(および作業を行うためのリポジトリ) には、個別のオブジェクトが必要です。ドメイン オブジェクトのパブリック インターフェイスは、ほとんどの場合、すべてが void メソッドであり、パブリック ゲッターはありません。この例は、注文ステータスです。

public class Order { // this is the domain object  
  private Guid _id;
  private Status _status;

  // note the behavior here - we throw an exception if it's not a valid state transition
  public void Cancel() {  
    if (_status == Status.Shipped)
      throw new InvalidOperationException("Can't cancel order after shipping.")
    _status = Status.Cancelled;
  }

  // etc...
}

public class Data.Order { // this is the persistence (EF) class
  public Guid Id;
  public Status Status;
}

public interface IOrderRepository {
  // The implementation of this will:
  // 1. Load the EF class if it exists or new it up with the ID if it doesn't
  // 2. Map the domain class to the EF class
  // 3. Save the EF class to the DbContext.
  void Save(Order order); 
}

#2 に対する答えは、DbContext が EF クラスへの変更を自動的に追跡することです。

于 2012-12-28T01:58:03.430 に答える
2

答えはノーです。EF コード ファーストの最も優れた点の 1 つは、ビジネス オブジェクトを手動で作成する必要があるため、DDD にうまく適合することです。そのため、EF モデルを使用して DDD エンティティおよび値オブジェクトと同等にする必要があります。複雑なレイヤーを追加する必要はありません.DDDがどこでもそれを推奨しているとは思いません.

エンティティに IEntity を実装させ、値オブジェクトに IValue を実装させ、さらに残りの DDD パターン、つまりリポジトリに従って、データベースとの実際の通信を行うこともできます。これらのアイデアの多くは、.NET でこの非常に優れたサンプル アプリケーションを見つけることができます。最初は EF コードを使用していませんが、それでも非常に価値があります: http://code.google.com/p/ndddsample/

于 2012-11-04T16:26:09.893 に答える
2

最近、私は同様のプロジェクトを行いました。私はこのチュートリアルに従っていました:リンク そして、私はこのようにそれを行いました: 私は空のソリューションを作成し、プロジェクトを追加しました: ドメイン、サービス、および WebUI。

簡単に言うと、ドメインにモデルを配置しました（たとえば、EFコードのクラス、メソッドなど）。サービスは、ドメインがasp.net webapiを使用して世界（WebUI、MobileUI、他のサイトなど）と通信するために使用されました。WebUiは実際にはMVCでした。アプリケーション (ただし、モデルはドメイン内にあったため、ほとんどが VC でした)

私が助けたことを願っています

于 2012-11-04T21:51:51.020 に答える
1

Pluralsight コース:エンタープライズにおけるエンティティ フレームワークでは、 EF Code First を組み込んだドメイン駆動設計のこの正確なシナリオに進みます。

1番については、どちらの方法でもできると思います。それは単にスタイルの問題です。2 番目については、ビデオのインストラクターがこれを説明するためにいくつかの方法を使用しています。1 つの方法は、値を変更するときにクライアント側で設定されるすべてのクラスに「State」プロパティを設定することです。次に、DbContext は、どの変更を永続化するかを認識します。

于 2012-11-04T13:27:47.457 に答える
0

このトピックに関する遅い質問。Josh Kodroff の回答を読むと、たとえば Entity Framework DAL へのリポジトリの実装に関する私の考えが裏付けられます。

ドメイン オブジェクトを EF 永続化オブジェクトにマップし、保存時に EF に処理させます。取得するときは、EF がデータベースから取得し、それをドメイン オブジェクト (集約ルート) にマップして、コレクションに追加します。

これはリポジトリ実装の正しい戦略ですか?

于 2013-09-13T09:45:56.000 に答える