APIを介したドメインモデルの公開

作業しているWebベースのアプリケーション用のシンプルなRESTful APIを構築しています。ドメインモデルを公開するための最良の方法について考えています。

Userクラスがあり、JSONレスポンスにさまざまなユーザープロパティを提供したいとします。セキュリティと帯域幅の問題のため、モデルのすべてのプロパティ（DateCreated、PasswordHashなど）を公開したくないのは明らかです。

私はデータ転送オブジェクトを読みましたが、これが進むべき道かどうか疑問に思っています。私が正しい場合、たとえば、ユーザーモデルをユーザーDTOに渡し、そのDTOが選択したユーザープロパティの公開のみを許可することを確認できます（これは、モデルをパブリックAPIから分離するのにも役立ちます）。

この解決策は適切ですか、またはこれについてより良い方法がありますか？

ありがとう。

これが、DTOが存在する理由の1つです。

ここでのトレードオフは、DTOを追加すると実装が少し複雑になり、エラーが発生しやすくなることです（ドメインオブジェクトとDTOのマッピングの不一致など）。これには単体テストを使用してください！

DTOで実行できる、RESTfulサービスで見過ごされがちなもう1つのことは、参照、ネストされたオブジェクト、および可能な操作のハイパーテキストデータを処理することです。

Martin FowlerのPoEAAを参照してください： 「[...]もう1つの利点は、ワイヤーを介してデータを転送するためのシリアル化メカニズムをカプセル化することです。このようにシリアル化をカプセル化することにより、DTOはこのロジックをコードの他の部分から除外しますまた、必要に応じてシリアル化を変更する明確なポイントも提供します。」

http://martinfowler.com/eaaCatalog/dataTransferObject.html

TL; DR：DTOSを介してドメインロジックと「RESTful配線」の懸念を分離するというアイデアが気に入っていますが、より複雑な設計を導入しています。

これはデータ転送オブジェクトの主な目的ではありませんが、DTOを使用して、プレゼンテーションモデルのデータ部分と同様の方法でこの問題を解決できます。

指摘したように、これはデザインを膨らませる可能性があり、追加されたフィールドと同じくらい単純なものは、追加のレイヤーを介してバブルアップするための変更を必要とする場合があります。このため、オブジェクトのシリアル化を説明するメタデータを提供できるかどうかを確認することをお勧めします。多くの言語では、これはDTOへの面倒な変換を回避するためにドメインオブジェクトに適用できる特別な注釈の形式をとります。Jacksonのようなパッケージ（Mixinsの使用による）は、メタデータをドメインモデルから完全に分離するために、この考えを少し遠くに持っていることがよくあります。