ドメイン主導設計での要求/応答のモデリング
私がUserクラスを持ち、そのユーザーがId＆Nameを持っているとします。リクエストレスポンスモデリングでは、Nameを使用してリクエストを作成し、IdとNameを使用してレスポンスを作成するため、ドメインモデルは次のようになります。
public User
{
public int Id { get; set; }
public string Name {get; set; }
}
SOA（web api））では、常にNULLのIDを使用してリクエストを行うので、これはわずかに無駄になります。次に、詳細に触れない複雑なものにスケーリングしてみましょう。たとえば、ユーザーには20個のプロパティがあり、そのうち5個は複雑なオブジェクトなので、httpリクエストは増加します。もっと面白くするために、これらのプロパティの一部をUIに公開できないとします（例：ハッシュとソルト）。
SOAドメイン駆動設計を使用したアーキテクチャ）でこの一般的なシナリオを処理するための推奨アプローチは何ですか？
編集：私の質問は、ドメインをdtoに変換するよりも要求/応答を扱っています。要点は、要求= dto＆応答= dtoだと思います。
ドメイン駆動設計はこれに対する答えを提供しません。 DDDはビジネスロジックにより重点を置いています。問題は、ネットワークを介してクライアントとの間で送受信される文字列としてデータを表現する方法です。
必要なのはデータ転送オブジェクト（DTO）です。プロセス間でデータを転送する必要があり、別のプロセスへの呼び出しが（通常はHTTPリクエストの場合のように）操作の負荷が高い部分である場合は常に、送信されるデータに特化したクラスまたはクラスのグループが必要です。動作ではありません—データ、およびデータのみ。 DTOは、パブリックゲッターとセッターを持つ傾向があります。他のDTOで構成することもできますが、メソッドを含めることはできません。
これらのDTOの構造は、サービス指向アーキテクチャーのように、ネットワークを介して送信するために、それらを文字列にシリアル化するために使用できます。 Martin Fowler は、DTOのシリアライゼーションとデシリアライゼーションを同じオブジェクトで結合することをお勧めします（つまり、DTOにメソッドを追加することを意味します）。これは、サードパーティのライブラリでも実現できます。すべての技術スタックには、JSONおよびXMLとの間で変換するためのライブラリがあり、これらはかなり標準的なデータ形式です。これらのライブラリは、クラスリフレクションを利用して、オブジェクトメンバーと型情報からデータ構造を推測することがよくあります。