サービスは常にDTOを返す必要がありますか、それともドメインモデルも返すことができますか

大規模なアプリケーションを（再）設計しています。DDDに基づく多層アーキテクチャを使用しています。

データレイヤー（リポジトリの実装）、ドメインレイヤー（ドメインモデルとインターフェイスの定義-リポジトリ、サービス、作業単位）、サービスレイヤー（サービスの実装）を備えたMVCがあります。これまでのところ、すべてのレイヤーでドメインモデル（主にエンティティ）を使用し、ビューモデルとしてのみDTOを使用しています（コントローラーでは、サービスはドメインモデルを返し、コントローラーはビューに渡されるビューモデルを作成します）。

DTOの使用、使用、マッピング、および受け渡しに関する無数の記事を読んだことがあります。明確な答えはないことを理解していますが、ドメインモデルをサービスからコントローラーに返すかどうかはわかりません。ドメインモデルを返しても、コントローラーは常にビュー固有のビューモデルを作成するため、ドメインモデルはビューに渡されません。この場合、正当なようです。一方、ドメインモデルがビジネスレイヤー（サービスレイヤー）を離れると、適切に感じられません。サービスはドメインで定義されていないデータオブジェクトを返す必要がある場合があります。その場合、マップされていないドメインに新しいオブジェクトを追加するか、POCOオブジェクトを作成する必要があります（一部のサービスはドメインモデルを返すため、これは醜いです。効果的にDTOを返します）。

問題は、ビューモデルを厳密に使用する場合、ドメインモデルをコントローラーに返すことは問題ありませんか、それとも、サービスレイヤーとの通信に常にDTOを使用する必要がありますか？その場合、必要なサービスに基づいてドメインモデルを調整しても問題ありませんか？（率直に言って、私はそうは思いません。サービスはドメインが持っているものを消費する必要があるからです。）厳密にDTOに固執する必要がある場合、サービスレイヤーで定義する必要がありますか？（私はそう思います。）DTOを使用する必要があることは明らかです（たとえば、サービスが多くのビジネスロジックを実行して新しいオブジェクトを作成する場合）。ドメインモデルのみを使用する必要がある場合もあります（たとえば、Membershipサービスが貧血のUser（ s）-ドメインモデルと同じDTOを作成することはあまり意味がないようです）-しかし、私は一貫性と優れた実践を好みます。

記事ドメインvs DTO vs ViewModel-それらをいつどのように使用するか？（および他のいくつかの記事）は私の問題と非常に似ていますが、この質問には答えません。記事EFのリポジトリパターンでDTOを実装する必要がありますか？も同様ですが、DDDは扱いません。

免責事項：存在していてファンシーであるためにデザインパターンを使用するつもりはありません。一方、アプリケーション全体の設計に役立ち、分離に役立つため、優れたデザインパターンとプラクティスを使用したいと思います。特定のパターンを使用するのは難しいとしても、少なくとも現時点では「必要」ではありません。

いつもありがとうございます。

ドメインモデルがビジネスレイヤー（サービスレイヤー）を離れると、正しくない

ガッツを正しく引き出しているように感じますか？Martin Fowlerによると、サービス層はアプリケーションの境界を定義し、ドメインをカプセル化します。つまり、ドメインを保護します。

サービスはドメインで定義されていないデータオブジェクトを返す必要がある場合があります

このデータオブジェクトの例を提供できますか？

厳密にDTOに固執する必要がある場合、サービスレイヤーで定義する必要がありますか？

はい、応答はサービス層の一部なので。「別の場所」で定義されている場合、サービスレイヤーはその「別の場所」を参照して、ラザニアに新しいレイヤーを追加する必要があります。

ドメインモデルをコントローラーにすべて返すのは問題ありませんか、それともサービスレイヤーとの通信には常にDTOを使用する必要がありますか？

DTOは応答/要求オブジェクトです。通信に使用すると意味があります。プレゼンテーションレイヤー（MVC-Controllers / View、WebForms、ConsoleApp）でドメインモデルを使用している場合、プレゼンテーションレイヤーはドメインに密結合されているため、ドメインを変更すると、コントローラーを変更する必要があります。

ドメインモデルと同じDTOを作成してもあまり意味がないようです）

これは、新しい目にとってのDTOの欠点の1つです。今、あなたは考えていますコードの重複をていますが、プロジェクトが拡大するにつれて、特に異なるチームが異なるレイヤーに割り当てられているチーム環境では、それはより理にかなっています。

DTOはアプリケーションをさらに複雑にする可能性がありますが、レイヤーも同様です。DTOはシステムの高価な機能であり、無料ではありません。

DTOを使用する理由

この記事では、DTOを使用するメリットとデメリットの両方を提供します。 //guntherpopp.blogspot.com/2010/09/to-dto-or-not-to-dto.html

次のように要約：

いつ使用するか

• 大規模なプロジェクトの場合。
• プロジェクトの寿命は10年以上です。
• 戦略的、ミッションクリティカルなアプリケーション。
• 大きなチーム（5人以上）
• 開発者は地理的に分散しています。
• ドメインと表示が異なります。
• オーバーヘッドデータ交換の削減（DTOの本来の目的）

使用しない場合

• 中小規模のプロジェクト（最大5メンバー）
• プロジェクトの寿命は2年程度です。
• GUI、バックエンドなどのための個別のチームはありません。

DTOに対する議論

• コードの複製。
• 開発時間のコスト、デバッグ。（DTO生成ツールhttp://entitiestodtos.codeplex.com/を使用）
• 両方のモデルを常に同期する必要があります。
• 開発コスト：追加のマッピングが必要です。（https://github.com/AutoMapper/AutoMapperのような自動マッパーを使用します）
• なぜデータ転送オブジェクトはアンチパターンですか？

DTOを使用した引数

• DTOがない場合、プレゼンテーションとドメインは密接に結合されます。（これは小さなプロジェクトでは問題ありません。）
• インターフェイス/ APIの安定性
• 絶対に必要な属性のみを含むDTOを返すことにより、プレゼンテーションレイヤーを最適化できます。linq-projectionを使用すると、エンティティ全体をプルする必要はありません。
• 開発コストを削減するには、コード生成ツールを使用します

DDDアプローチを実行することを決定したので、アプリケーションは十分に大きく、複雑であるようです。pocoエンティティまたはいわゆるドメインエンティティとサービスレイヤーの値オブジェクトを返さないでください。これを行う場合は、サービスレイヤーを削除します。もう必要ないためです。ビューモデルまたはデータ転送オブジェクトはドメインモデルメンバーにマップする必要があるため、サービスレイヤーに存在する必要があります。では、なぜDTOが必要なのでしょうか。多くのシナリオがある複雑なアプリケーションでは、ドメインとプレゼンテーションビューの懸念を分離する必要があります。ドメインモデルはいくつかのDTOに分割でき、いくつかのドメインモデルはDTOに縮小できます。したがって、モデルと同じであっても、階層化アーキテクチャでDTOを作成することをお勧めします。

サービスレイヤーとの通信には常にDTOを使用する必要がありますか？ はい。ドメインモデルメンバーを使用してサービスレイヤーのリポジトリと通信し、それらをDTOにマップしてMVCコントローラーに戻る、またはその逆を行うときに、サービスレイヤーでDTOを返す必要があります。

必要なサービスに基づいてドメインモデルを調整してもよいですか？ サービスはリポジトリとドメインメソッドおよびドメインサービスと通信するだけです。ニーズに基づいてドメイン内のビジネスを解決する必要があります。ドメインに必要なものを伝えるのはサービスタスクではありません。

厳密にDTOに固執する必要がある場合、サービスレイヤーで定義する必要がありますか？はい、サービスレイヤーのドメインメンバーにマップする必要があり、DTOをアプリケーションのコントローラーに配置することはお勧めしません（サービスレイヤーでリクエストレスポンスパターンを使用してみてください）。 ！

私の経験では、実用的なことをする必要があります。「最高のデザインは、機能する最もシンプルなデザインです」-アインシュタイン。それが心です...

ビューモデルを厳密に使用している場合、ドメインモデルをコントローラーに返すのは問題ありませんか。それとも、サービスレイヤーとの通信に常にDTOを使用する必要がありますか？

絶対大丈夫です！ドメインエンティティ、DTO、ビューモデルがある場合、データベーステーブルを含めると、アプリケーションのすべてのフィールドが4か所で繰り返されます。私は、ドメインエンティティとビューモデルが問題なく機能する大規模なプロジェクトに取り組んできました。これに対する唯一の例外は、アプリケーションが分散され、サービスレイヤーが別のサーバーに存在する場合です。この場合、シリアル化の理由でDTOをネットワーク経由で送信する必要があります。

その場合、必要なサービスに基づいてドメインモデルを調整しても問題ありませんか？（率直に言って、サービスはドメインが持っているものを消費する必要があるので、そうは思いません。）

ドメインモデルは通常、ビジネスロジックを反映しており、通常はそのロジックのコンシューマーによって形作られるわけではないため、一般的に私は同意し、ノーと言います。

厳密にDTOに固執する必要がある場合、サービスレイヤーで定義する必要がありますか？（私はそう思う。）

それらを使用することに決めた場合、私は同意し、そうだと思います。結局のところ、サービスレイヤーはDTOを返すのに最適な場所です。

幸運を！

私はこのパーティーに遅れましたが、これは非常によくある重要な質問であり、対応を余儀なくされました。

「サービス」とは、ブルーブックでEvanが説明した「アプリケーション層」を意味しますか？私はあなたがそうすることを仮定します、その場合の答えは彼らがDTOを返すべきではないということです。「ドメインの分離」というタイトルの青い本の第4章を読むことをお勧めします。

その章では、エヴァンスはレイヤーについて次のように述べています。

複雑なプログラムをレイヤーに分割します。各レイヤー内に、まとまりがあり、下のレイヤーのみに依存するデザインを開発します。

これには正当な理由があります。ソフトウェアの複雑さの尺度として半順序の概念を使用する場合、層をその上の層に依存させると、複雑さが増し、保守性が低下します。

これを質問に当てはめると、DTOは実際にはユーザーインターフェイス/プレゼンテーションレイヤーの懸念事項であるアダプターです。リモート/プロセス間通信がDTOの目的であることに注意してください（その投稿では、FDDが必ずしもDDD言語を話しているわけではありませんが、サービスレイヤーの一部であるDTOについては反対していることに注意してください）。

アプリケーション層がこれらのDTOに依存している場合、それはその上の層に依存しており、複雑さが増します。これによりソフトウェアのメンテナンスが難しくなることを保証できます。

たとえば、システムが他のいくつかのシステムまたはクライアントタイプとインターフェイスし、それぞれが独自のDTOを必要とする場合はどうなりますか？アプリケーションサービスのメソッドが返すDTOをどのようにして知るのですか？選択した言語が戻り値の型に基づいたメソッド（この場合はサービスメソッド）のオーバーロードを許可しない場合、どのようにしてその問題を解決しますか？そして、あなたが方法を見つけたとしても、なぜプレゼンテーション層の懸念をサポートするためにアプリケーション層に違反するのでしょうか？

実際には、これはスパゲッティアーキテクチャで終わる道への一歩です。私はこの種のデボルブとその結果を私自身の経験で見てきました。

私が現在働いている場所では、アプリケーション層のサービスがドメインオブジェクトを返します。インターフェース（UI /プレゼンテーション）レイヤーは以下のドメインレイヤーに依存しているため、これは問題とは見なされません。に。また、次の理由により、この依存関係は「参照のみ」のタイプの依存関係に最小化されます。

a）インターフェイス層は、アプリケーション層への呼び出しによって取得される読み取り専用の戻り値として、これらのドメインオブジェクトにのみアクセスできます。

b）アプリケーション層のサービスのメソッドは、その層で定義された「生の」入力（データ値）またはオブジェクトパラメータ（必要に応じてパラメータ数を減らすため）のみを入力として受け入れます。具体的には、アプリケーションサービスはドメインオブジェクトを入力として受け入れ。

インターフェース層は、インターフェース層自体内で定義されたマッピング手法を使用して、ドメインオブジェクトからDTOにマップします。繰り返しますが、これにより、DTOは、インターフェイスレイヤーによって制御されるアダプターであることに焦点を合わせたままになります。

パーティーには遅れますが、まったく同じタイプのアーキテクチャに直面しており、「サービスからのDTOのみ」に傾いています。これは主に、オブジェクト内の有効性を維持するためにドメインオブジェクト/集合体のみを使用することを決定したためです。つまり、更新、作成、または削除するときのみです。データを照会するときは、EFをリポジトリーとしてのみ使用し、結果をDTOにマップします。これにより、読み取りクエリを自由に最適化し、ビジネスオブジェクトに適応させないようにすることができます。多くの場合、データベース関数を使用しているため、高速です。

各サービスメソッドは独自のコントラクトを定義するため、長期にわたって維持するのが簡単です。私は願います。

これまでのところ、すべてのレイヤーでドメインモデル（主にエンティティ）を使用しており、DTOはビューモデルとしてのみ使用しています（コントローラーでは、サービスはドメインモデルを返し、コントローラーはビューモデルを作成してビューに渡します）。

ドメインモデルは用語を提供するため（ユビキタス言語）アプリケーション全体に）をするため、ドメインモデルを広く使用することをお勧めします。

ViewModels / DTOを使用する唯一の理由は、（任意の種類のプレゼンテーションレイヤー）と（ドメインモデル）を分離するためのアプリケーションでのMVCパターンの実装です。この場合、プレゼンテーションとドメインモデルは疎結合です。ViewModel

サービスはドメインで定義されていないデータオブジェクトを返す必要がある場合があります。その場合、マップされていないドメインに新しいオブジェクトを追加するか、POCOオブジェクトを作成する必要があります（一部のサービスはドメインモデルを返すため、これは醜いです。効果的にDTOを返します）。

私はあなたがアプリケーション/ビジネス/ドメインロジックサービスについて話していると思います。

可能な場合はドメインエンティティを返すことをお勧めします。追加の情報を返す必要がある場合は、複数のドメインエンティティを保持するDTOを返すこともできます。

ドメインエンティティを介してプロキシを生成する第3部のフレームワークを使用する人々は、サービスからドメインエンティティを公開するのに困難を感じることがありますが、それは誤った使い方の問題にすぎません。

問題は、ビューモデルを厳密に使用する場合、ドメインモデルをコントローラーに返すことは問題ありませんか。それとも、サービスレイヤーとの通信に常にDTOを使用する必要がありますか？

99,9％のケースでドメインエンティティを返すのに十分だと思います。

DTOの作成を簡素化するために、それらにあなたのドメインエンティティをマッピングすることは、あなたが使用できるためにはAutoMapperを。

ドメインモデルの一部を返品すると、契約の一部になります。コンテキスト外のものがそれに依存するため、コントラクトを変更するのは困難です。そのため、ドメインモデルの一部を変更しにくくすることになります。

ドメインモデルの非常に重要な側面は、変更が簡単なことです。これにより、ドメインの変化する要件に柔軟に対応できます。

次の2つの質問を分析することをお勧めします。

1. 上位レイヤー（ビューとビューモデル/コントローラー）は、ドメインレイヤーが公開しているものとは異なる方法でデータを消費していますか？多くのマッピングが行われている場合、またはロジックさえ含まれている場合は、設計を再検討することをお勧めします。おそらく、データが実際に使用される方法に近いはずです。

2. 上層を深く変える可能性はどのくらいありますか？（ASP.NETをWPFに交換するなど）。これが非常に異なり、アーキテクチャがそれほど複雑でない場合は、できるだけ多くのドメインエンティティを公開することをお勧めします。

私はそれが非常に広いトピックであると思います、そしてそれは本当にあなたのシステムがいかに複雑であるかとその要件に行き着きます。

私の経験では、オブジェクトオブジェクトのUIパターン（ネイキッドオブジェクトなど）を使用していない限り、ドメインオブジェクトをUIに公開することはお勧めできません。これは、アプリケーションが成長するにつれて、UIからのニーズが変化し、オブジェクトがそれらの変更に対応するように強制するためです。最終的に2つのマスター（UIとドメイン）を提供することになりますが、これは非常に辛い経験です。私を信じて、あなたはそこにいたくありません。UIモデルにはユーザーとの通信機能があり、ビジネスルールを保持するDOMAINモデルと永続モデルはデータの効果的な格納を扱います。これらはすべて、アプリケーションのさまざまなニーズに対応します。私はこれについてブログの投稿を書いている最中です。完了したら追加します。