問題タブ [domain-driven-design]

DDD は、集約ルートを介してのみエンティティにアクセスする必要があると述べています。たとえば、多くの子 Y エンティティを持つ可能性のある集約ルート X があるとします。ここで、いくつかのシナリオでは、一度にこれらの Y エンティティのサブセットのみを本当に気にします (おそらく、それらをページ付きリストなどに表示しています)。

その場合、そのようなシナリオで不完全な集計を返すようにリポジトリを実装しても問題ないでしょうか? すなわち。Ys コレクションである X オブジェクトには、関心のある Y インスタンスのみが含まれ、すべてではありませんか? これにより、たとえば、Y を含む何らかの計算を実行する X のメソッドが期待どおりに動作しない可能性があります。

これはおそらく、問題の Y エンティティが集約ルートに昇格されたと見なされるべきであることを示しているのでしょうか?

私の現在のアイデア (C#) は、LINQ の遅延実行を利用して、X オブジェクトが Y との関係を表す IQueryable を持つようにすることです。このようにして、フィルタリングを使用して透過的な遅延読み込みを行うことができます... ORM（私の場合はLinq to Sql）を使用するのは少し難しいかもしれません。

他に賢いアイデアはありますか？

典型的なシナリオ。internallyサーバー ファームと複数の分散クライアントおよびローカル クライアントとの間の通信には、昔ながらの XML Web サービスを使用します。サードパーティは関与せず、自社と顧客が使用するアプリケーションのみを使用します。

XML WS現在、モデルへの移行を検討しWCF/object-basedており、さまざまなアプローチを試しています。そのうちの 1 つは、ドメイン オブジェクト/集合体をワイヤ経由で直接転送し、それらの DataContract 属性を呼び出す可能性があります。

で Order プロパティを使用するIExtensibleDataObjectことにより、単純なプロパティのバージョン管理の問題に対処できるはずです (すべてのクライアントを制御し、簡単に強制更新できることを思い出してください)。DataContractDataMembers

DTOs専用の転送専用のデータ転送オブジェクト ( ) をネットワーク経由で使用する必要があるとよく耳にします。

なんで？それでもそうする理由はありますか？サーバー側とクライアント側で同じドメイン モデルを使用します。もちろん、コレクションの事前入力などは、正しく「必要」と判断された場合にのみ行います。コレクション プロパティは、サービス ロケーターの原則と IoC を利用してNHibernate-based、(サーバー側で) データを直接フェッチする"サービス" と、サーバー ファームWCFと対話するクライアント側の "サービス" クライアントのいずれかを呼び出します。WCF

では、なぜ を使用する必要があるのDTOsでしょうか。

ドメインモデルをWCFサービスAPIにプッシュすることを検討しており、このタイプのセットアップでの遅延読み込み手法についていくつか考えてみたいと思います。

このアプローチを取るときに何か提案はありますか？

この手法を実装してアプリにステップインすると、サーバーがリストを返す直前に、遅延読み込みされるはずの各プロパティの取得にヒットします...したがって、読み込みが熱心になります。この問題を説明したり、解決策を提案したりできますか？

編集：XMLIgnore属性を使用できるようですので、シリアル化中には見ら​​れません..まだこれを読んでいます

Contact、TelephoneNumber、および ContactRepository という単純なドメイン モデルがあります。連絡先はエンティティであり、ID フィールドがあります。TelephoneNumber は典型的な値オブジェクトです。ID がなく、Contact インスタンスとは別に読み込むことができませんでした。

反対側からは、連絡先を操作するための Web アプリケーションがあります。最初のページは「ContactList」、次のページは「Contact/C0001」で、連絡先の詳細と電話番号のリストが表示されます。

電話番号編集フォームを実装する必要があります。最初に考えられる近似は、「ThelephoneNumber/T0001」のようにナビゲートできるページを追加することです。

しかし、ThelephoneNumber は Value Object クラスであり、そのインスタンスはこの方法では識別できませんでした。

この問題を解決するためのベスト プラクティスは何ですか? ステートレス アプリケーションで識別不可能なオブジェクトを識別するにはどうすればよいでしょうか?

Domain Driven Design を読み終えたところですが、そこで取り上げられているいくつかのアイデアに魅了されています。プロジェクトでユビキタス言語を実装している企業を知っていますか?

DDDを読み始めたばかりです。エンティティと値のオブジェクトの概念を完全に理解することはできません.値オブジェクトがエンティティオブジェクトとして設計されている場合にシステムが直面する可能性のある問題 (保守性、パフォーマンスなど) を誰かが説明できますか? 例は素晴らしいでしょう...

EvanとNilssonの本を読んだ後でも、ドメイン駆動プロジェクトでデータアクセスを管理する方法がわかりません。CRUDメソッドがリポジトリの一部である必要があります（つまり、OrderRepository.GetOrdersByCustomer（customer））か、エンティティの一部である必要があります：Customer.GetOrders（）。後者のアプローチはよりOOのように見えますが、単一のエンティティタイプのデータアクセスを複数のオブジェクト、つまりCustomer.GetOrders（）、Invoice.GetOrders（）、ShipmentBatch.GetOrders（）などに分散します。挿入と更新はどうですか？

最後に、NHibernate を利用したドメイン モデルでマルチテナント機能の透過的で流暢なサポートを実装するための最良の戦略は何かを説明してもらえますか?

TenantID によるフィルタリングなど、マルチテナントのものからドメイン ロジックを可能な限り分離する方法を探しています。

それで、私のチームの開発者の1人からこの質問を受けました：ドメイン駆動設計とは何ですか？もちろん、エヴァンスの本を指すこともできますが、それは実際に答えですか？

チームのジュニアソフトウェアエンジニアに、DDDを数文でどのように説明しますか？

さびた古いhbmファイルでドメインモデルを宣言しました。javax.persistence。*アノテーションが付けられたPOJOに移動したいと思います。

誰かがそうする経験がありますか？

使用できるツールはありますか？