DTO
Urushihara Takeru用語集
構造的部分型(Structural Subtyping)
構造的部分型（Structural Subtyping）は、型システムの一つであり、オブジェクトやデータ型の互換性をその構造に基づいて判断する方式です。構造的部分型では、オブジェクトや型が持つメンバーの構造（プロパティやメソッドの存在や型）が一致していれば、互換性があると見なされます。
派生: duck typing、多態性
公称型（Nominal Typing）
公称型（Nominal Typing）は、型システムの一つであり、型の互換性を名前に基づいて判断する方式です。公称型では、型の互換性は型の名前（またはクラス名）によって確定されます。
一般的に、型が同じ名前を持つか、同じクラスを継承している場合に互換性があると見なされます。つまり、型の構造やメンバーの一致は重要ではなく、型の名前が一致していれば互換性があるとされます。
DTOアセンブラ（DTO Assembler）
DTOアセンブラ（DTO Assembler）は、ソフトウェア開発において、エンティティ（またはドメインオブジェクト）からDTO（Data Transfer Object）への変換を行う役割を持つコンポーネントまたはクラスです。
Urushihara TakeruDTOのセマンティックのギャップ
技術ブログを見漁っている限り、DTOは2つのセマンティックで語られることがあると思った。
- 外部ネットワークを越すためのPOJO（多分こっちが本来のDTO）
- DAOの吸収レイヤーとしてのオブジェクト（Local DTOといった類のもの）
DTOは元々データ転送のためのオブジェクトとして定義された言葉・概念であり、2のようなネットワークを越さないものは定義に沿わない。また、DTOはデータ転送に対して最適化されるべきであるので2のようなビジネスロジックのマッピングのような利用用途も不適切である？
こちらの方の記事でまとめられている図がわかりやすい。レイヤードアーキテクチャとDDDとの混同が原因っぽい。
Urushihara TakeruDTOの使い所
One case where it is useful to use something like a DTO is when you have a significant mismatch between the model in your presentation layer and the underlying domain model.[1]
プレゼンテーションレイヤーのモデルとドメインモデルの間にミスマッチがある時にDTOは有用。確かにそうだが、ここでいうミスマッチは具体的に何なのか。シリアライゼーションに関係があるもの？隠蔽したいものがあること？Pのレイヤーで構造を最適化したい時のこと？
Urushihara Takeru所感
「ドメインオブジェクトはPOJO（推奨）！ORM Entityはドメインオブジェクトの一部！」という考え方でいくとDTOが必要な場面が結構なくなるのではないのかと思った。
エヴァンスは「ドメインモデルの核心はビジネスの概念を表現するべきであり、技術的な制約やフレームワークに依存すべきではない」みたいなことを言っている？のでそれはもうPOJOだろ。という気持ち。
ORMでドメインにインフラの知識入ってもうてるやんけというのは否定できないけど、ORMのコンテキスト外でPOJOとして振る舞えるのなら致命的な違反にはならないのではという気持ちになった。
例えばJavaで、ドメイン層においたJPAのORM Entityがあるとして、「そいつらにDBの定義マッピングしました。はいもうJPAのコンテキストプロバイダーなしでは動きません。」ということにはならない。むしろ、「別にプロバイダーなくてもnewできますやん、あなたDTOで地道にDBとドメインオブジェクトマッピングする気ですか？正気ですか？」っていう風になる。
直感的だが、これはJavaの言語仕様とかライブラリの抽象の仕方の限界で、もしかしたらこういう矛盾（インフラ風味のドメインオブジェクト）は別のアプローチなら解決できるのかもしれないと無責任に思った。「確かにORMはインフラ層なんや、、気持ち悪くてもこうするのが結果効率いいんやで。」というので結論付けちゃっていい気がした。これからお気持ちが変わることもあるだろうが。
何よりiDDDの本の方がHibernateをドメインモデル層で使ってるのが背中を押してくれた。