ドメインモデルとプレゼンテーション層

ちくわさん「画面にはドメインオブジェクトを渡す派」
http://d.hatena.ne.jp/thata/20050824#1124858180

ドメインオブジェクトとViewHelperで十分派。ローカルDTOは、プレゼンテーション層のモデルとドメインモデルとの間に大きなミスマッチがある場合に使うぐらい。

ひがさん「プレゼンテーションモデルをどこで変換するのか」
http://d.hatena.ne.jp/higayasuo/20050824#1124874756

プレゼンテーションモデルとドメインモデルをどこで変換したらよいのかは難しい問題です。私は、ビジネスロジック層で変換したほうが良いと考えていますが、その理由は2つあります。
1つは、チームに必要とされる知識と開発者のレベルです。
（中略）
2つめは、O/R Mapperのlazy loading問題です。

あたりを読んで・・・
画面にはドメインオブジェクトを渡す派は、本来のOOP的な考えにマッチしてるように思える。ドメインのモデルをどう整形して表示してるか、ソースに直接書いてあって、トレーサビリティが高い。凝集度が高いといってもいいかもしれない。
一方、プレゼンテーションモデルをビジネスロジック層で変換する派だと、プレゼンテーション層とビジネスロジック層の間の結合度が下がる感じがする。プレゼンテーション層とビジネスロジック層は、JSPとJavaBeanというように技術的な違いがあるので、開発チーム内で柔軟に分担したいならこちらがよいか。
プログラミングの方法から見ると、画面にはドメインオブジェクトを渡す派のほうがpull的というか、画面がデータを欲しがるときにとってくるという感じ。プレゼンテーションモデルをビジネスロジック層で変換する派は、バッチ処理的にプレゼンテーションモデルを作って「おら、表示しろ」って感じ。前者の方がOOPチックでスマート、後者のほうは汎用機出身の人なんかにはわかりやすいかも。

私の失敗事例（Strutsをはじめて使った。当時は1.0.1だったか）でいうと、

ドメインモデル（DTO、lazy loadingはなし）をJSPで表示する形でスタート
やっぱそれだけじゃむずい、ViewHelperも導入しよう
（プロジェクトに内憂外患が発生して大混乱に）
遅れを取り戻すため、Javaを知らない、ASPなら少しは知ってる、という人を何人か投入
この人たちにHTML（UIモック）をJSPに変換してもらうしか・・・
（既存のメンバーに）藻前らJSPはいいからプレゼンテーションのためのDTO（当時はValueObjectとか呼んでたような、でドメインモデルのDTOをValueObjectと呼んでたのでViewObjectとか適当な名前をつけた）を作ってください

って流れで、一つのアプリケーションに違うパターンが混在するようにしちゃった。
このときから、保険のつもりでプレゼンテーションモデルのDTOをつくる癖がつきますた（っていうか、それ以降あんまりJ2EEで業務アプリの開発ってやってないな）。