DDD モデル プロジェクトは完全に分離し、アプリケーションの他のレイヤーを参照しないようにする必要があること、および WCF サービスには、WCF サービスに必要なすべての特別な属性を備えた実際のモデル オブジェクトの DTO バージョンが含まれることを理解しています。サービスはモデルも参照し、DTO と「実際の」モデル オブジェクト間の変換方法を認識します。
私が知りたいのは、このサービスを使用しているクライアント アプリケーションが、DTO オブジェクトまたは実際のモデル オブジェクトのどちらを使用して通信する必要があるかということです。クライアント アプリケーションは、サービスから受け取った DTO オブジェクトをモデル バージョンに変換する必要がありますか?それとも、クライアントが DTO オブジェクトを直接処理しないようにサービスに組み込む必要がありますか?
サービスのインスタンスをラップし、同じ機能を DTO バージョンではなくモデル オブジェクトとして公開するラッパー クラスを作成することを考えていました。良いアイデア？悪いアイデア？
次の記事はあなたの質問に答えるはずです
MicrosoftとMartin Fowler のData Transfer Object に関する説明を参照することを忘れないでください。
さらに。クライアント側で注意してください。dto の変更によって大量のコーディングが発生しないようにしてください。
WCF は「実際のモデル クラス」を理解せず、DTO のみを理解します。クライアント コードは、これらの DTO (またはシリアル化されたペイロード) を何らかの方法で理解する必要があります。したがって、あなたの質問は、クライアントとサーバーの両方から同じドメイン モデル クラスを使用できるかどうかです。
サービスのインスタンスをラップし、同じ機能を DTO バージョンではなくモデル オブジェクトとして公開するラッパー クラスを作成することを考えていました。良いアイデア？悪いアイデア？
構築しているアプリケーションの種類と、展開に関する制限事項によって異なります。
クライアントとサーバーの両方から直接ドメイン オブジェクトを参照するということは、それらを同時にアップグレードする必要があることを意味します。たとえば、'User' エンティティに 'Name' 属性があり、それを 'First' と 'Last' に分割することにした場合、クライアント、サーバー、およびデータ ストアを同時に更新する必要があります。これは単なる例であり、モデルの動作の変更はさらに問題になる可能性があります。何かが変更されたときにスタック全体を再デプロイする準備ができていれば、あなたのアプローチは問題ないようです。この場合、「ラッパー」を回避して、このコードを代替のリポジトリ実装として使用することもできます。つまり、クライアント用とサービス用の 2 つのリポジトリ実装を試すことができます。クライアント リポジトリの実装では、基になるデータ ストアとして WCF サービスを使用します。
一方、サーバー上の変更からクライアントを分離することをお勧めします。この場合、メイン ドメイン モデルはサービスによってのみ参照され、クライアント固有の DTO としてクライアントに公開されます。このようにして、クライアントに影響を与えることなく、ドメイン モデルとサービス コードを自由に進化させることができます。クライアントは、サーバーから受け取った DTO に基づいて入力する独自のバージョンのモデル クラス (場合によっては「サブモデル」) を持っている可能性があります。