3

DDD、パターン、およびアプリケーション アーキテクチャの他の多くのトピックについて読んだときに、何ヶ月もかき回されてきた疑問が頭に浮かびました。これを MVC Web アプリケーションの観点から組み立てますが、問題はもっと広い範囲にあると確信しています。それは次のとおりです。ドメイン エンティティへの固執は、アプリケーションに硬直性と非効率性をもたらしますか? 

DDD アプローチは、アプリケーションのビジネス ロジックを管理し、利害関係者と連携する方法として完全に理にかなっています。しかし、私にとっては、多層アプリケーションのコンテキストではうまくいきません。つまり、ビューがエンティティのすべてのデータを必要とする場合、または 2 つのリポジトリでさえすべてを持っている場合のシナリオはほとんどありません。それ自体は悪いことではありませんが、複数のクエリを作成して一連のプロパティを返すことを意味します。そして、それが完了すると、余分な情報がビューに渡されるか、データを破棄、マージ、および DTO またはビュー モデルにマッピングするオーバーヘッドが発生します。多くのレポートを生成する必要があり、そこで問題が拡大しているようです。それぞれが独自の情報のスライスまたは集約を必要とし、SQL ではうまく機能しますが、リポジトリではうまくいきません。完全なエンティティを返すことが期待されます。正直なところ、これは無駄に思えます。原則として、データベースをパウンディングして不要なネットワーク トラフィックを生成したくはありません。このような質問から リポジトリ層はデータ転送オブジェクト (DTO) を返す必要がありますか? この質問に苦労しているのは私だけではないようです。では、それが課すと思われる制限に対する答えは何ですか? 

新しい混乱した DDD-er からの感謝。  

4

4 に答える 4

6

ここでの本当の問題は何ですか？ビジネス ルールの処理とデータのクエリは、2 つの非常に異なる問題です。その実現は、CQRS - Command-Query Responsibility Segregation につながります。あれは何でしょう？両方のタスクに同じモデルを使用するわけではありません。ドメイン モデルは、動作、ビジネス プロセスの実行、コマンドの処理に関するものです。また、表示に使用される別のレポート モデルがあります。一般に、ビューごとにテーブルを含めることができます。これらのテーブルには関連情報のみが含まれているため、DTO、AutoMapper などを取り除くことができます。

これら 2 つのモデルはどのように同期しますか? それは多くの方法で行うことができます:

  • レポーティング モデルは、データベース ビューの上に構築できます
  • データベースの複製
  • ドメイン モデルは、各変更に関する情報を含むイベントを発行でき、レポーティング モデルの適切なテーブルを更新するデノーマライザーによって処理できます。
于 2012-06-28T20:04:27.930 に答える
3

DDD、パターン、およびアプリケーション アーキテクチャの他の多くのトピックについて読んだことがあります。

ドメイン駆動設計は、パターンやアーキテクチャに関するものではなく、ビジネス ドメインに従ってコードを設計するものです。リポジトリやレイヤーについて考える代わりに、解決しようとしている問題について考えてください。「リハビリを開始する」最も簡単な方法は、名前ProductRepositoryを justに変更することですProducts。

ドメインエンティティへの固執は、アプリケーションの硬直性と非効率性を生み出しますか?

非効率性は、モデリングの悪さに起因します。[引用が必要]

DDD アプローチは、アプリケーションのビジネス ロジックを管理し、利害関係者と連携する方法として完全に理にかなっています。しかし、私にとっては、多層アプリケーションのコンテキストではうまくいきません。

層は層ではない

つまり、ビューがエンティティのすべてのデータを必要とする場合、または 2 つのリポジトリでさえすべてを持っている場合のシナリオはほとんどありません。それ自体は悪くありませんが、複数のクエリを作成して多数のプロパティを返すことを意味します。

必要に応じてそのデータをクエリします。問題を「既成の解決策」に閉じ込めようとしないでください。代わりに、それらから学び、それらを解決するために必要なことだけを適用してください。

それぞれには、SQL で適切に実行できる情報の一意のスライスまたは集計が必要ですが、完全なエンティティを返すことが期待されているため、リポジトリではできません。

http://ayende.com/blog/3955/repository-is-the-new-singleton

では、それが課すと思われる制限に対する答えは何ですか?

「らしい」

ところで、インターネットはこのようなものでいっぱいです(私はそのサンプルアプリを意味します)。
DDD とは何かを理解するには、ブルーブックをゆっくりと注意深く読んでください。2回。

于 2012-06-29T10:48:04.377 に答える
0

それぞれには、SQL で適切に実行できる情報の一意のスライスまたは集計が必要ですが、完全なエンティティを返すことが期待されているため、リポジトリではできません。

IOrderRepository.GetByCustomer など、必要なものだけを返すメソッドをリポジトリに追加します。DDD ではまったく問題ありません。クエリ オブジェクト パターンまたは仕様を使用して、リポジトリをより汎用的にすることもできます。リポジトリのインターフェースで ORM 固有のものを使用しないことを忘れないでください (例: NHibernate の ICriteria)。

于 2012-06-30T11:45:15.117 に答える
0

本格的な DDD は自分のシナリオにとって負担が大きすぎると思われる場合は、一歩下がって Active Record に近いものを検討する必要があるかもしれません。

私は DDD を使用していますが、私のシナリオでは複数のフロントエンドをサポートする必要があります。いくつかの Web サイトと WinForms アプリ、および他の自動化されたプロセスとの対話を可能にする一連のサービスです。この場合、余分な複雑さはそれだけの価値があります。DTO を使用して、データの表現をさまざまなプレゼンテーション レイヤーに転送します。ドメイン エンティティを DTO にマッピングする際の CPU オーバーヘッドは小さく、ネットワーク呼び出しやデータベース呼び出しと比較すると丸め誤差です。この複雑さを管理するオーバーヘッドもあります。AutoMapperを使用して、これをある程度軽減しました。マイ リポジトリは、完全に入力されたドメイン オブジェクトを返します。サービス層は DTO との間でマッピングされます。ここでは、ドメイン オブジェクトをフラット化したり、ドメイン オブジェクトを結合したりして、より表形式のデータを生成できます。

Dino Esposito は、このテーマに関する MSDN マガジンの記事をここに書いています。

だから、あなたの「なぜ」の質問に答えると思います-いつものように、それはあなたの文脈に依存します. DDD はおそらく労力がかかりすぎます。その場合、もっと簡単なことをしてください。

于 2012-06-28T19:34:43.150 に答える