私はドメイン モデルの可視性に関する興味深い議論に参加していましたが、ここにいる人々が適切なガイダンスを持っているかどうか疑問に思っていました。
これについてのコメントと考えを期待しています。
すべての助けに感謝します！
いいえ、それは MDA の目的ではありません。システムの動作を指定するために高レベルの表記 (UML とそのアクション言語) を使用して、特定のプラットフォームから自分自身を隔離することです。
ドメイン モデルを公開する必要があるかどうかは、アプリケーションによって異なります。アプリケーションを定期的に使用するユーザー (IDE について考えてみてください) の場合、ドメイン モデルは明らかに公開されており、そのドメイン内のオブジェクトを直接操作します。ただし、ときどき使用されるアプリ (チェックイン用の空港のキオスクを考えてみてください) の場合、アプリはワークフローを通じてユーザーをガイドする必要があります。
ドメイン オブジェクトを保護する場合でも、DTO は必ずしも必要ではありません。これは、ドメイン オブジェクトが UI をレンダリングするレイヤーと同じプロセス空間にあるかどうかによって異なります。DTO を必要とするアーキテクチャは、DRY の原則に違反しているため、新しい要件への適応があまり得意ではありません。
実際、直接公開されたドメイン オブジェクトのみからエンタープライズ アプリを構築することは可能です。これが Naked Objects パターンの目的です。オリジナルの Naked Objects Framework (Java 上) など、これを実装するオープン ソース フレームワークがいくつかあります。.NET に相当する商用版もあります。
ドメイン オブジェクトに関する一般的な議論については、Evans の著書 Domain-Driven Design を参照することをお勧めします。yahoo にもアクティブなニュースグループがあります。
ダン
完全な開示: 私は Java の NOF のコミッターであり、.NET バージョンには直接関与していません。
私はダンに同意します。これに取り組む1つの方法は、インターフェースを使用することです。パブリックメソッドが、ドメインオブジェクトが最初に実装するインターフェイスを返すようにします。アプリケーションからドメインオブジェクトを返すことが機能しなくなった場合は、DTOを導入し、関連するインターフェイスを実装します。ライブラリの内部が変更されましたが、消費するアプリケーションは影響を受けません。
私はこの分野にあまり精通していませんが、最近、Gojko Adzicによるこのブログ投稿を読みました。これは、DTOが必ずしも良いアイデアではないこと、およびドメインモデルを別々の層で繰り返しても問題ないことについて関連していると思います。 DRYに違反しないように。