1

私はDDDにかなり慣れていないので、ここに私のジレンマがあります：

エンティティ B への参照を持つエンティティ A を永続化する必要があります (両方ともエンティティ ルートであると考えてください)。UI レイヤーは、これらすべての情報を (コントローラーで) A_DTO (A の DTO クラス) を介して収集し、属性を DTO から A の新しいインスタンスにマップします。次に、 A の B への参照のために、UI は ID を送信します。リポジトリの背後で ORM を使用しているため、 BRepository から B のオブジェクト インスタンスを検索し、作成中の新しい A インスタンスに参照を設定し、最後に ARepository.save(A インスタンス) を呼び出します。

ここにはいくつかのオプションがあります

  1. これらすべてを UI レイヤー (コントローラーまたは何らかのサービス ファサードのいずれか) で実行するか、
  2. createA という ApplicationService またはドメイン Service でこれを行います。

どちらのオプションが正しいでしょうか??. ここで本当に際立っているのは、ID で B をルックアップして A オブジェクトの set への参照を取得するプロセスです。これは、ORM を維持するためのプロセスまたはドメイン モデルの一貫性を維持するためのプロセスと同様に主張できます。B の参照を A に設定するプロセスには、いくつかの暗黙のビジネス ルールと検証が存在する可能性があります。これらが、ここでの決定の原動力になっていると思います。

また、エンティティの作成プロセスでバリデーションが織り込まれ、UI を介してクライアントにバブルされ、別のリポジトリによる検証のレベル ?? またはコントローラーで発生する明示的なステップとして??

4

2 に答える 2

1

DTO は、UI レイヤー内でデータを転送するための便利なクラスにすぎません。ID を使用して B を参照するという事実は、UI レイヤーの実装の詳細です。したがって、ID を参照に変換するなど、DTO をドメイン オブジェクトにマップするのは、UI レイヤー/コントローラーの仕事である必要があります。

一方、検証は当然ドメイン層に属します。この点で、UI の唯一の仕事は、ドメイン オブジェクトに値を設定し、それによって発生したエラーを表示することです。

于 2012-07-23T03:22:13.163 に答える
0

どちらのオプションも正しいと見なすことができますが、アプリケーションサービスによって提供されるカプセル化がコードの読み取りと理解に役立つため、オプション2を好む傾向があります。また、ドメインのAPIの統合も簡単になります。オプション1over2を支持する議論は、もちろんあなたが裁判官であるにもかかわらず、アプリケーションサービスの使用から生じるカプセル化の追加の層は不必要な複雑さであるということです。検証は通常、プレゼンテーション層やドメイン層など、アプリケーションのいくつかの層で明示されます。検証ロジックを一度作成して、他の場所で再利用するのが理想的です。実際には、通常、検証ロジックを複製する方が簡単です。つまり、ASP.NET MVCなどのプレゼンテーション層には、ビューモデル用の独自の検証宣言があります。次に、アプリケーションサービスとドメインエンティティも、そのコンテキストで必要な検証を実行する必要があります。の私の投稿を見てくださいこれらのトピックに関する詳細な議論のためのDDDでのサービスとDDDでの検証。

于 2012-07-22T23:28:53.067 に答える