[解決済み] DTOをDomain Objectにマッピングするためのベストプラクティス？

質問

マッピングに関する質問をよく見かけます。 DTO をドメインオブジェクトにマッピングすることに関する多くの質問を見ましたが、私の質問に答えているとは思えませんでした。 私は以前に多くの方法を使用し、私自身の意見を持っていますが、私はもう少し具体的なものを探しています。

状況です。

私たちは多くのドメインオブジェクトを持っています。 私たちはCSLAモデルを使用しているので、ドメインオブジェクトはかなり複雑になり、独自のデータアクセスを含んでいます。 これらのオブジェクトを通信でやり取りするのは好ましくありません。私たちは、多くのフォーマット（.Net、JSONなど）でデータを返す新しいサービスをいくつか書く予定です。 このため（および他の理由）、私たちはワイヤー上で渡すための無駄のないデータ転送オブジェクトも作成します。

私の質問は、DTO とドメイン オブジェクトはどのように接続されるべきか、ということです。

私の最初の反応は ファウラー、DTOパターン型の解決策 . 私はこれが行われるのを何度も見てきましたし、私にとっては正しいことだと感じています。 ドメイン オブジェクトには、DTO への参照は含まれていません。 外部のエンティティ（マッパーまたはアセンブラ）が呼び出され、ドメイン オブジェクトから DTO が作成されます。 通常は ORM がドメインオブジェクト側にあります。 この欠点は、実際の状況に応じてマッパーが非常に複雑になる傾向があり、非常に壊れやすくなることです。

提示された別のアイデアは、DTO が単なるリーン データ オブジェクトであるため、ドメイン オブジェクトに DTO を含めるというものです。 ドメイン オブジェクトのプロパティは内部的に DTO プロパティを参照し、要求された場合は DTO を返すことができます。 これには何の問題もありませんが、間違っているように感じます。 私は、いくつかの記事で NHibernate を使用している人がこの方法を使用しているように見えるいくつかの記事を見ました。

他の方法はないのですか？ 上記の方法のうち、一つでも使う価値がありますか？ もしそうなら、あるいはそうでないなら、その理由は？

どのように解決するのですか？

ドメインと DTO の間に位置するマッパーを持つことの利点は、単一のマッピングしかサポートしていないときにはあまり明らかではありませんが、マッピングの数が増えるにつれて、そのコードをドメインから分離することで、ドメインをよりシンプルで無駄のないものに保つことができます。余分な重量でドメインが乱雑になることはないでしょう。

個人的には、私はマッピングをドメインエンティティから切り離し、私が「マネージャ/サービス層」と呼ぶものに責任を負わせるようにしています。これは、アプリケーションとリポジトリの間に位置する層であり、ワークフローの調整などのビジネスロジックを提供します（Aを変更する場合、サービスAがサービスBで動作するようにBも変更しなければならない場合があります）。

もし私が多くの可能な終了フォーマットを持っているなら、例えばエンティティを変換するためにVisitorパターンを使用できるプラグイン可能なフォーマッタを作成することを検討するかもしれませんが、私はまだこのように複雑なものの必要性を見つけていません。