データモデルはUIおよびドメインモデルにどの程度密接に対応していますか？
たとえば、Customerテーブル、Employeeテーブルなどがある場合、データモデルはドメインモデルに非常に近くなる可能性があります。
ただし、UIはデータモデルをそれほど厳密に反映していない可能性があります。たとえば、複数のフォームがあり、すべてが他のさまざまなデータと一緒に顧客データの断片をフィードしている場合があります。この場合、各フォームからのデータを保持するために別々のテーブルを持つことができます。必要に応じて、将来の時点でデータを組み合わせることができます...または、フォームデータをCustomerテーブルに直接挿入して、データモデルがUIと十分に相関しないようにすることもできます。
何があなたにとってより良く機能することが証明されましたか？
ドメインモデルを、解決しようとしている現実の問題にマッピングする方がクリーンだと思います。
次に、ビューに必要なすべてのデータのバケットとして機能するビューモデルを作成できます。
述べたように、UIは頻繁に変更される可能性がありますが、これは通常、取り組んでいる特定のドメインの問題を変更しません...
このパターンに関する情報はここにあります：
http://blogs.msdn.com/dphill/archive/2009/01/31/the-viewmodel-pattern.aspx
UIは多くのニーズに応じて変更される可能性があるため、一般に、データをドメインモデルに保持し、1つのUIから抽象化することをお勧めします。
RESTfulサービスレイヤーがある場合、それらがドメインモデルを公開しているもの。その場合、UI（特定の画面）はこれらのサービスの数を呼び出し、収集されたドメインモデルから画面を構成します。このシナリオでは、ドメインモデルはUIまでバブルしますが、UIレイヤーは、特定の画面を構築するために必要なデータをスキムアウトします。永続性のためのドメインモデル（注釈付き）の使用に関するSOに関するいくつかの興味深い質問もあります。ここでの私のポイントは、ドメインモデルが唯一の正しい情報源になり得るということです。それはデータを運ぶ仕事をすることができ、ロジックをかなりうまくカプセル化します。私は、各ドメインモデルをDTO、VO、DO、およびwhat-have-yousに変換する多くの定型コードを含むプロジェクトに取り組んできました。その多くは非常に不必要に見え、ほとんどの場合、習慣が原因です。