ドメイン駆動設計とWCFサービスアーキテクチャ
私はDDDパラダイム（DDDの完全な初心者）でプロジェクトを構築する方法を理解しようとしていて、Webサービスの実装に関する問題に遭遇しました...これらは私が見るいくつかのオプションです：
ファットクライアント、ファットサーバー（オプション1）：
- サーバ：
- リポジトリ層：データベースと通信し、ドメインオブジェクトを返すことができます。
- ドメインレイヤー：ビジネスロジックと検証を含むドメインオブジェクトが含まれます。
- サービス層：ドメイン層のファサードのように機能します。
- WCFレイヤー：サービスレイヤーをWebメソッドに公開します。ドメインオブジェクトを適切なDTOオブジェクトにマップします。
- クライアント：
- インフラストラクチャ層：WCFサービスを介してサーバーと通信します。 DTOオブジェクトをドメインオブジェクトにマッピングします。
- ドメインレイヤー：ビジネスロジックと検証を含むドメインオブジェクトが含まれます。
- サービス層：ドメイン層のファサードのように機能します。
- UIレイヤー（WinForms）：サービスレイヤーを使用してドメインオブジェクトと通信します。
良い：ドメインレイヤーがクライアントとサーバーの両方にあるため、検証は両方で行われます（クライアントにとっては良い-サーバーへの呼び出し回数が減ります、サーバーにとっては良いです-「ユーザーデータを信頼しない」ため）。
悪い例：検証が2回行われ、多くのマッピングが必要です（たとえば、データベースへの単純なクエリ：ドメイン（リポジトリから返されます）-> DTO（WCFに必要）->ドメイン（クライアントのドメインレイヤーに必要）-> DTO（ WinFormsの場合）ドメインの変更は、サーバーとクライアントに同時に展開する必要があります。
ファットクライアント、シンサーバー（オプション2）：
サーバ：
- リポジトリ：データベースと通信し、DTOオブジェクトを返します。
- WCFレイヤー：データベース呼び出しをWebメソッドに公開します。
クライアント：オプション1とまったく同じ。
良い例：クライアントでは、WCFサービスをDTOオブジェクトを返す通常のリポジトリとして扱うことができます。オプションnrの方が単純です。 1。
悪い点：リポジトリがドメインオブジェクトではなくDTOで動作することは問題ありませんか？また、サーバーは検証を実行しないため、データについてクライアントを信頼する必要があります。
シンクライアント、ファットサーバー（オプション3）：
サーバー：オプション1とまったく同じ。
クライアント：
- インフラストラクチャ層：WCFサービスを介してサーバーと通信します。
- UIレイヤー（WinForms）：プレゼンターを使用して、インフラストラクチャレイヤーのWCF呼び出しを介してサーバーと通信します。
良い：すべてのドメインロジックはサーバー上にあります。
悪い例：クライアントには検証が含まれていないため、サーバーに対して不必要な呼び出しを大量に行う可能性があります。
私は最初のオプションに傾いていますが、複雑すぎます...アドバイスや他のオプションはありますか？
私はオプション3を使いますが、次の注意事項があります。
- 仕事を成し遂げるためにクライアントが知る必要があるドメインロジックの量を試して減らしてください。クライアントで意味のある方法でそのデータを公開するサービスを作成します。これにより、クライアントでクランチを実行するのではなく、特定の条件を満たすドメインオブジェクトのコレクションをリクエストできます。
- 検証はクライアント側ではオプションであると考える必要があります。将来のクライアント実装が適切に行われることを保証することはできないからです。したがって、他の場所で行われていないかのように、常にサーバー側で検証します。もちろん、クライアントはクライアント側でも検証する必要があります。
- WCFデータをクライアント側の完全なドメインオブジェクトにマッピングする代わりに、それらをより単純なViewModelタイプのオブジェクト（クライアントに適切なプロパティのみを含む完全なドメインオブジェクトのスリムバージョン）にマッピングすることを検討してください。クライアントのプログラミングがより簡単になります。
あなたがまだ直面している問題は、たくさんのマッピングです。ドメインモデルへのクライアントの依存関係を削除すると、ドメインを変更する余地が生まれるため、この価格は支払う価値がある（そして AutoMapper などのツールを使用すると簡単になります）ため、マッピングを壊すことなくマッピングを微調整できますクライアントコード。